LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Multiple devices read on VISA port?

Hello,

 

I am new to LabVIEW but have enjoyed the learning experience!  I created a VI in LabVIEW 2014 for a Watlow process controller and Delta Controls process controller. I need data from both devices which are operating on a single machine.  In my first attempt, I placed both programs in the same While loop.  This failed with error messages regarding communication. Then,I placed each in a segment of a sequencer as well as separate While loops with Wait Until ms instructions in an attempt to allow them to work on the same com port with the loops switching back and forth.  Although both portions of the sequenced programs work as individual programs, they do not work when combined into the same VI.  They are both configured as Modbus RTU communications and the same baud rate.  I think I must be missing something fundamental regarding multiple devices on a single VISA node. Perhaps a different method of separation other than While loops and sequencing?  Please share your thoughts with this novice.

 

Chris

:mansad: 

0 Kudos
Message 1 of 8
(6,117 Views)

Hi Chris,

 

I’m glad to hear you’re enjoying the learning experience of LabVIEW! After looking at your code, it appears that you need to have separate VISA resources for your two controllers. A VISA resource is any instrument in your system. You can read more about NI-VISA at this link: https://www.ni.com/en/support/documentation/supplemental/06/ni-virtual-instrument-software-architect...

 

You mentioned both controllers being configured for Modbus. There are several ways to use Modbus communication that do not involve using VISA. We have a community page regarding the LabVIEW Modbus API, which you can find at this link: https://forums.ni.com/t5/Reference-Design-Content/LabVIEW-Modbus-API/ta-p/3524019

 

I do want to warn you, this particular free library is unsupported. If you want to use a supported Modbus API, you will need the LabVIEW Real-Time Module or the LabVIEW Datalogging Supervisory Control (DSC) Module. The above community page explains in more details which APIs are supported.

 

I hope this helps answer your question!

 

Regards,

Brittany V

Applications Engineering

0 Kudos
Message 2 of 8
(6,062 Views)

Brittany,

 

Thank you for the response and advice.  However, I am yet a bit unclear.  I have a single USB to RS485 interface to pass the data from both devices.  Are you indicating that I must have two separate devices and com ports? Perhaps simply add a separate VISA control which can refer to the same com port? I am excited to learn this.  I was just informed that I must pepare a VI with 22 devices like these.

 

Chris

0 Kudos
Message 3 of 8
(6,028 Views)

@cmengineer wrote:

Brittany,

 

Thank you for the response and advice.  However, I am yet a bit unclear.  I have a single USB to RS485 interface to pass the data from both devices.  Are you indicating that I must have two separate devices and com ports? Perhaps simply add a separate VISA control which can refer to the same com port? I am excited to learn this.  I was just informed that I must pepare a VI with 22 devices like these.

 

Chris


And here is where we go into trouble!

 

Just because I've been there before and learned some harsh lessons I've got to ask you if you have read the user's guides for the Watflow Controlers and the one for the Delta Controlers.  Have You?

 

Often these "Modbus" devices can share a single VISA Resource by including an "Address" in the data package so that only the addressed device responds to the message or command behind the address portion of the data delivered over the serial bus.  At Other times, the address is assumed by the serial bus resource that is physically connected.  MY experience would question if "Watflow" FW Engineer's interperatation of  "RS-485" is the same as "Delta"s FW Engineers interperatation!  (Side Note:  Did you that "RS" stands for Recommended Standard? Not every engineer follows recommendations!)  I have NOT read the manuals for your devices whatever they really are.  I would carefully consider the communication protocol of each before commiting them to the same phyisical bus.


"Should be" isn't "Is" -Jay
0 Kudos
Message 4 of 8
(6,016 Views)

Well here is an intersting twist: Attempting to correct the condition and a hint from Brittany's advice, I restructured the connection to the VISA control through the outside wall of the sequencer instead of through the joining wall. This appears to work but with a slight querk.  I get the error message shown in the attached image. However, once I click the continue button, the program works as it should.  I do not claim to understand it but perhaps it is a matter of passing the VISA connection incorrectly.  This is not a complete solution while the error message can occur.  I still want to understand this better.

 

Chris :mansurprised:

Download All
0 Kudos
Message 5 of 8
(5,999 Views)
Jeff,
I use these models daily and have read the manuals. I agree that the engineers who support these devices may have different interpretations of a protocol. However, I saw nothing in the manuals to make me think they were not compatability for Modbus communication together. I also noticed that the next time I ran the VI, no error message occured! Tomorrow, I begin the larger 22-device program!
0 Kudos
Message 6 of 8
(5,981 Views)

@cmengineer wrote:
Jeff,
I use these models daily and have read the manuals. I agree that the engineers who support these devices may have different interpretations of a protocol. However, I saw nothing in the manuals to make me think they were not compatability for Modbus communication together. I also noticed that the next time I ran the VI, no error message occured! Tomorrow, I begin the larger 22-device program!

OUTSTANDING! (Emphasis added)

 

I've had a hard day with my PC and you just restored my faith in SW Engineers! (But I may sound grumpier than I mean too sound so, forgive me in advance OK?)

 

Now, lets look at this statement... I also noticed that the next time I ran the VI, no error message occured!

 

OH Crap,  This can be easy... {Init the VISA Session before you use it} Trust me- like Nike says, Just do it!

 

 

OR it can get really complex...VISA Sessions do not need to be "Initiallized" if the current Windows settings are configured correctly!  There is a VISA "Memory" issue that you are running into....

 

To wit:   If a VISA Session is open AND its properties (Baud, Start, Stop, Parity, etc,...) are set then "untill the top level vi that called the vi that set those properties leaves memory the VISA session is held in limbo-land and those expressly reset properties are retained by VISA (unless you check the "Automatically close VISA Sessions" box in the Tools>>Options.Enviornments tab).  

 

To put it plainly, the init in the second frame is resetting the config for the serial port and VISA is hanging on to those settings while the VI is in memory.  (Totally unexpected but, correct behavior!)  OTOH, Without knowing and playing around at this (shall we say less than ideally documented) feature of VISA's interaction with LabVIEW, you can wind up wondering if there is an "Insane object between Monitor and Chair!"

 

Init your VISA Session before entering the loop.  Put the purple wire on a Shift Register.  Close the VISA Session after the loop. You need exactly ZERO sequence structures!  AND the damned Error chain is there for a reason! Keep it passing along and use some error handling! (just hit the search feature to get ideas on that)

 

 


"Should be" isn't "Is" -Jay
0 Kudos
Message 7 of 8
(5,963 Views)

I have to admit I really like the Icon banner...and no, I am not a member of "The World Taekwondo Federation"


"Should be" isn't "Is" -Jay
0 Kudos
Message 8 of 8
(5,949 Views)