loss of serial communication and LV

[jdezman]

I have lost the ability to communicate with my temperature controllers via LabVIEW. I recently upgraded my hardware from ioTech's Personal DAQ 56 to the NI cDAQ 9174. I have also had to tweak my code so that it uses NI-DAQmx VI's, rather than the Windows XP-compatible drivers from ioTech. My code is intended to read thermocouples, as well as read/write values from/to temperature controllers. I have the modules 9213,9201, and 9403 in my cDAQ, and I also have the NI USB-to-Serial cable connecting my PC to Watlow Series 96 Temperature Controllers.

-The initial problem was that I could only write temperatures a couple times before the communications would cease, then I couldn't write or read from the temp controllers. The TC continue to read w/o issue. 

-Now, it will only display either 8 or 9 temp controllers' values (out of 10).  I am also unable to write anything. If I try to write a new temperature to the controllers, the temp doesn't make it thru, and then the front panel displays show a value of zero.

-I receive the error: -1073807339

-I have the program Comm7 to test the serial connection, and I can read and write with Comm7, with no issues.

To me, it seems as if timing is the issue. Somehow the reading and writing timing conflict, then  the Comm port gets tied up so nothing else can happen. I have checked all connections in my setup and shifted around which ports the USB's plug into without a change in result.

[AnalogKid2DigitalMan]

Here is a good starting point on the causes/solutions to that error. You may also need a delay between your writes and reads in case the instruments need time to process the commands.

http://digital.ni.com/public.nsf/allkb/E6DFA2B8D7E99F9886256C14005E82F7

P.S. Were you over at Engineering Tips site recently?

-AK2DM

[jdezman]

Forgot to say that I use producer-consumer loops with a Modbus driver to handle the read/write to the temperature controllers.

[Anthony_F]

jdezman,

To make the problem more clear, you have having trouble with the temperature controller connected to the USB to serial adapter, correct?  The thermocouples read fine from the thermocouple input module?

Can you successfully read and write values to the temperature controller using a VISA test panel in Measurement and Automation Explorer?

Have you always had the temperature controller connected to this USB to serial adapter?  What changes did you make when you could 'write temperatures a couple times ' to 'display either 8 or 9 temp controllers', was this what prompted the hardware change?

[jdezman]

Anthony,

-Yes, I am having issues with the temp controllers connected to the USB-Serial adapter. The thermocouples read fine from the input module.

-I don't know how to use it nor the syntax for communicating thru the VISA test panel. I only have read that the *IDN\ text means nothing. I have looked for a users guide and syntax for operating but have had no success.

- Yes, the controllers were always connected via the adapter. My setup was working last Friday, then there was a power outage over the weekend. I don't understand how that would've caused issues, but that is the only change that I recall. The hardware change was prompted by the fact that the ioTech equipment was only supported thru Windows XP, and this change was made a month ago. The goal was to match and optimize the hardware and software.

[Anthony_F]

jdezman,

Thanks for the background info. I forgot you were dealing with MODBUS and that you can't use test panels in the same way as other devices.

Did you take a look at the knowledge base article that refers to the error you are having (-1073807339)?  Is this error coming from the MODBUS VIs or do you have a VISA read/write someone else on your block diagram?

What commands are you sending to the temperature controller that gives back the error?  I see you have some global variables, are you using a Real Time system or communicating between multiple LabVIEW programs?

[jdezman]

Anthony,

I did look at the knowledge base article but it wasn't helpful.  The error is coming from the Modbus VI's that came from Watlow; however, these contain VISA read/write within them. I am not using a Real Time system, but rather have the capability of multiple LabView VI's running simultaneously (actually one reentrant VI that has a separate instance for each furnace that is running).  Any command sent to the controller will generate the error.

Further testing has shown the following: the problem is only caused by communication to the controller address number 9 (the controllers are on a single daisy chain RS-485 serial connection).  Once the Modbus VI times out, all communication is lost with all of the controllers.  If I quit out of LabView and go back in I can communicate with the controllers again (until I try to communicate with #9).  On the controllers themselves, I set the address of controller 9 to 1 and 1 to 9.  I was still not able to communicate with address 9 (now controller 1) so this proves that it is not a hardware issue.  One additional piece of information that might be relevant is that I recently migrated to Windows 7 (64-bit).  I haven't run the system much since making the switch so this problem may be related and simply went undetected for a bit.

[jdezman]

Hi Anthony,

Here is another update on my serial communication problem.  After more testing I discovered that this issue is not restricted to address 9 (as stated in my previous post).  Also, the problem does not always occur (i.e., sometimes I can communicate with all 10 controllers for a short period of time).  When I first go into LabView I can generally communicate with all of the controllers.  Eventually, one of the controllers timesout and I lose communication with all of the controllers.  This mainly seems to happen when I send a number of commands quickly to the controllers so that they build up in the queue.  It seems as though some of the commands are getting corrupted or there is some data loss in the queue.  I think that this is why controllers 9 and 10 seem to have the most problems, because I usually start at controller 1 so the commands for 9 and 10 sit in the queue the longest.  Also, it seems that once I have a communication problem with one controller it seems to linger for a while.  For example if controller 9 timesout, then even if I quit out of LabView and communicate with it through another program (e.g., Comm 7) when I go back into LabView again I still may have problems communicating.  Usually after some "fiddling around" (e.g., turning the controller off and on again, running the Modbus VI by itself, etc.) I eventually regain communication, only to have a different controller drop out.  Is it possible that some bad command gets written to some buffer and takes a while to clear out?  Can my data get corrupted when written to or from a queue?  I have placed an indicator on the queue and all of the command values appear correct.

[Anthony_F]

"this mainly seems to happen when I send a number of commands quickly to the controllers so that they build up in the queue."

When you say that you are sending a number of commands quickly, you are referring to the user interface part, correct? In your code you have a 500 ms wait in the for loop and a 250ms wait in the consumer loop.  Additionally the for loop runs twice so the consumer loop only sends commands every 1.25 seconds, this doesn't seem very fast at all.

Is there a reason you are running the for loop twice?

This may seem like a silly question, but do you have terminating resistors at the beginning and at the end of your daisy chain?

[jdezman]

Anthony,

That loop was run twice to insure that the write values would make it to the controller, because some of the communications with the old hardware required 2 writes. In the port settings, I do have the Bias Resistors enabled. I turned them off to compare results, and with the resistors off, the Comm7 program was unable to talk to the controllers. I would still appreciate more info on those resistors, if you wouldn't mind.

I have done a significant amount of testing and probing of my code up to this point, only to get erratic results. I just now was able to pin down the fact that my communications issue seems to be tied to the number of furnaces/temp controllers I talk to. Initially, the code would poll all ten temp controllers with every loop iteration. I changed the code so that it searches for the indices of the controllers that are on, then it only polls the controllers that are on. I then tested the communications with 1,2,etc on up to 7 controllers and everything worked great. When I added the eighth, active controller, it would read 7 of them before timing out on the eighth and tying up communications. This is confusing to me, because sometimes I achieve 7, sometimes 8, controllers behaving as I would like. I realize 8 is a commonly used number in computer programming, so I was wondering if that had something to do with my issues?