LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Error 1 with Watlow Driver

I am communicating with Watlow EZ-Zone controllers from Labview.  Harware interface is USB485/4 to watlow's RS-485.  the program runs well for a long time (as much as several days).  However, an a few occasions Labview reports "Error 1 Occurred at Unspecified Location".  Since this error message waits for an operator response, the program essentially crashes.

I tracked this error message to a write call to WatbusInterfaceDll.dll:WatbusInterface_Init, called from the watlow driver vi Write.vi that I downloaded from the NI web site.

I was able to see the error message occur when writing a correct string -- the same string that had been written many times previously.

Any thought on why this might occur would be appreciated.

0 Kudos
Message 1 of 8
(3,868 Views)

Hoard,

 

Is there anyway for you to reproduce the crash conditions? Maybe we are writing and reading faster than the device can respond. Can you try reading and writing in a while loop and see if you can reproduce the crash consistently? If you cannot zero in on the error, and it doesn't affect your program, you may be able to use some error handling to catch that specific exception and then go-to another action, though I don't recommend ignoring any error. 

Richard S -- National Instruments -- (former) Applications Engineer -- Data Acquisition with TestStand
0 Kudos
Message 2 of 8
(3,853 Views)

A two part answer:

I was able to create a similar failure: We are requesting a set point using the write command.  the watlow controller has a configuration parameter setting a maximum allowable set popint.  If you command a higher set point, the Watlow unit returns an error; this shows up as this error message -- not a very easily recognized situation, but we have corrected that.

 

However, we also have encountered the error when we were not changing the set point and I am not completely certain it even comes from the Watlow driver.  When it happens, Labview locks completely so it is hard to know which module the error comes from.

 

Another issue we have encountered may or may not be related: if we insert a mamory stick in the USB port to transfer some files, on some occasions when we remove it (even after "safely remove USB device"), the cDAQ stops gathering data.  Since we communicate with the Watlow over a USB485/4, is it possible that the real issue is something to do with USB communications?  I don't know how to tell is the USB is nearing maximum capacity.  We have 4 cDAQ 8-module chassis with all but one slot in use -- though only 1 Hz data rates.  Also, the USB485/4 and a USB232/4, USB mouse and keyboard.

 

Thanks for your help.

0 Kudos
Message 3 of 8
(3,842 Views)

Are you using a USB hub to plug in the USB485/cDAQ chassis/memory-stick/keyboard/mouse? There could potentially be a problem with the USB port itself. To discover the mode of failure when labVIEW locks up you can run a spy capture. When the system does lock up do you get any error messages, or does it just freeze?

Richard S -- National Instruments -- (former) Applications Engineer -- Data Acquisition with TestStand
0 Kudos
Message 4 of 8
(3,832 Views)

I am also having problems communicating with the EZ-Zone PM.  I am running a Modbus RTU network so the drivers below do not work for me.  I have verified communication using a visual  basic program that reads the float (L/H) output at address 360 (i.e. 40361).  When I try to use labviews modbus drivers i can see that the controller is pinged and I get a response of some sort but the number is something like 4750 and erratic.  I think I need to convert this from the float (L/H) to a decimal but I don't know how to do this.  Should I be recieving two numbers, one for the low and one for the high?  How can I program labview to convert these?  I appreciate your help.

0 Kudos
Message 5 of 8
(3,758 Views)

Are you using the NI Modbus Library for LabVIEW  or a Modbus I/O Server in DSC.   You should be able to set that you are reading a 2 byte number and it should automatically read both bytes.  

 

Also you mention it reads 4750 but what value are you expecting?

 

Finally, it might be helpful if you post your code so we can see what's might be going wrong. 

0 Kudos
Message 6 of 8
(3,732 Views)
Modbus transfers data in 8 bit bytes. It is up to the labview code to convert those bytes into words, double words, and floating point. Possibly using a typecast function with a U16, I16, Float array wired to the type input.
0 Kudos
Message 7 of 8
(3,710 Views)

Thanks for the quick reply.  What is a typecast function?  I am using the MB Serial Master Query Read Holding Registers vi to read the holding registers which does not have a type input........  I have attached my code. 

0 Kudos
Message 8 of 8
(3,694 Views)