.NET Driver and Win 7 64 bit

[cmarcus]

Hi All,

I've got an application that has been migrated from Windows XP SP3 to Windows 7 64-bit. I'm having trouble with something that may be the .NET driver, but I'm not 100% sure.

When I run my application everything seems fine, but after doing a few calls to read values from the PLC, I'm starting to see my application lock up. Investigating further, it seems to be locking up while waiting for a response from the .NET driver to read a single memory bit value. It seems like sometimes there is a long delay anywhere from 3 seconds to a full blown lock up that requires me to kill the application.

I'm just wondering if I need to do anything special with the driver, like recompile for x64 or anything?

Any help would be appreciated.

[Saragani]

Hi, first try to see if other Unitronics .Net based programs lock on Windows 7 64 Bit.... For example SD Card Explorer or Remote Operator.

If they doesn't lock then it might suggest a some kind of a fault in your program that causes a dead-lock in the Communication Driver.

You did not mention what kind of connection you use: Ethernet, Serial, Listener?

If you do use Serial connection, is it a USB To Serial (with Prolific driver)?

Sometimes the locks can happen inside the Communication Driver due to bad drivers (in the case of the Prolific USB to Serial).

Any information you can supply might help.

[cmarcus]

Hi Saragani,

Thanks for the response. I am using serial communications (standard 57600, 8, N, 1). I am also using a serial gear 8 port USB to serial converter with the FTDI chip set. Here's the link: http://serialgear.com/Industrial-Serial-Adapters-USBG-8COM-M.html

The application uses two instances of the Unitronics .NET driver to talk to load parameters into two separate PLC's. (One PLC acts as the main drive controller, and controls web tension load cells and four drive motors, the second PLC acts as an Edit controller handles evaluating the real time results of digital inputs, loading and analyzing the shift registers, and delivering digital signals to the motor controller commanding the motor controller to Run, Jog, Stop, Forward, Reverse, etc.) Both PLC's use the COM 2 port pitch data back to the application and display the realtime statistics of the production run along with any alarms or alerts.

The PLC code is sold and works extremely well. Unfortunately I did not write the original .NET application but have been tasked with migrating it over. And unfortunately the application is a bit of a mess from a structure standpoint, however the original version that used the Active X control on an XP platoform did work as expected.

My first step for this was to move all function calls from the Active X to the .NET driver. Once complete, I recompiled the code (on my XP machine) with the platform "Any Processor" and deployed it to the machine's Windows 7 machine. Everything seemed to work well but after a few hours, the operators are noting the long delays and lock ups. These I've been able to trace specifically to sending the Write Command to the PLC and getting a response.

The two things I have not tried yet, is download the .NET driver source code and recomplie it with a target platform of Any Processor or x64, and install .NET onto a Windows 7 64 bit machine and compile it. But I'm not sure if this would be the proper next steps.

Sorry for the long e-mail but I wanted to give as much detail as possible.

[Saragani]

OK, so the .Net program was never tested on Windows XP, so you can't be sure if the locks also happens there.

I do see that serialgear is also using prolific chips (and I hope the FTDI is not using the same driver as prolofic. My guess would be not).

Can you run the .Net program on XP and see if it also locks?

Can you test other .Net programs like Remote Operator on windows 7 and see if it also locks?

Can you have the .Net program connect to the PLCs using Ethernet, instead of Serial port connection?

The ActiveX communication driver is single threaded without locks and with DoEvents (to prevent UI thread from locked and UI from not responding).

The .Net driver is Multi-Threaded, can work with several PLCs at the same time (while managing messages queue) and have locks to prevent threads from changing data which is commonly used by them (For example, 2 threads enqueuing or dequeuing messages from the queue. Without the locks, there would be exceptions).

I can't really suggest a solution or see why it fails without seeing the code.

I hope that running Remote Operator (while connected to both PLCs) would not lock, cause it will then will suggest that the fault is with the program (which is easier to debug, other than the communication driver).

[cmarcus]

Ok, I tested it with remote operator and everything works fine. I then tested the .NET driver with an XP machine and it locked up. So it sounds like there's something in the application that is causing the lock up. It looks like I'm going to have to re-write large parts of it anyway, so hopefully when I formally redo the PLC communications class I'll get this problem resolved.

Thanks again for all your help.

-Chris

[Saragani]

Hi, I would gladly take a look at your code on my spare time.

Maybe I can find the problem.