LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Alternating writing to two serial channels

Solved!
Go to solution
Highlighted

Hi Everyone,

I need to send commands (writing only, no reading) to two identical serial devices, both of which are connected to my computer via serial to USB cables. Both devices work fine on their own, but when I try to run a vi that controls both of them (without changing any channels, cables, etc.), only the first device will receive commands.  The vi is set up such that I alternate sending commands (command 1 to device A, then command 1 to device B, then command 2 to device A, then command 2 to device B, etc.) In this situation, device A receives command 1, then device A receives command 2, etc.  I get no errors.  Anyone know what's going on?  My code is attached but you won't be able to run it because it calls several proprietary sub-vis that I am not allowed to post (those vis work fine, I've tested them extensively.)  Thanks in advance!

0 Kudos
Message 1 of 16
(255 Views)

Erica,

 

     Please get rid of that Stacked Frame Structure with 18 Levels!  The simplest thing to use to replace it is a For Loop with 18 wired to N, inside a Case Structure wired to the Index ("i") control of the Loop with additional Cases for 2 through 17.  Use Shift Register and/or Tunnels where necessary.  You will find it much easier to trace the wires between states without having to follow all the "ins and outs" of the Stacked Frame.

 

     I"m reasonably sure you have a "wiring error", but it is too tortuous to follow with Stacked Frames.

 

     Note that a For + Case structure is closely related to the structure of a State Machine, a Very Useful Design.

 

Bob Schor

0 Kudos
Message 2 of 16
(240 Views)

Hi Bob,

Thanks for the feedback, but I'm 99% sure it's not a wiring error.  I'm also not sure I understand how the structure you're proposing is an improvement over my current setup, because I need the program to do 18 different things in sequence.  I usually use a for loop when the program is doing basically the same thing multiple times, which it's not in this case.  It is noteworthy that in this program, there is nothing inside the frame structure has output that is used in another frame-- there are only constants outside the entire frame structure which I bring into different frames as needed.

Thanks,
Erica

0 Kudos
Message 3 of 16
(232 Views)

I'll echo Bob's request to get rid of the stacked sequence structures. Convert that stuff into subVI's, it'll help you in the long run.

 

Still, to answer your question, there is no serial communication code in what you posted, so it's a problem with the code that calls each instrument. I know you *think* it works fine, but it's clearly not working, so there is an issue where there must be something not closed correctly or a reference is left hanging. We won't be able to help you without more code.

0 Kudos
Message 4 of 16
(222 Views)

Thanks for the comment. Unfortunately I cannot post or modify the subVI that actually sends the serial commands, as it is a proprietary pump driver.  You feed in serial commands as strings and it sends the signal out to the hardware.  I am confident this subVI works well on its own.  What I'm wondering is whether I need to explicitly close a serial connection before sending a signal to another instrument, and if so, how to do that.  It is notable that if I stop the vi, switch the order of the serial input channels, and run it again, I can control only instrument B instead of just instrument A, but I have to actually stop the vi in order to get this to work.  What happens to the serial connection status when I stop the vi, and is there a way to make the program do that internally?  Thank you!

0 Kudos
Message 5 of 16
(216 Views)

Yes, on the Visa pallet there's a "Close" function.

0 Kudos
Message 6 of 16
(210 Views)

Error case 6 is getting over-written. Try putting some shift registers on the for loop so you can see all the errors, not just the last one.

image.png

 

After that, use standard debug techniques.

- You can try turning execution high lighting on and watch to see if your program is doing what you think it is.

- Create a much simpler test vi that sends a cmd to both devices

...

 

Good luck

0 Kudos
Message 7 of 16
(207 Views)

I tried that, but it does not seem to do anything.  I wonder if I'm using the function incorrectly.  Do you have any sample vi's that show how to use this function correctly?  Also, does the close function apply to a channel as a whole, or do you have to specify a specific device?  My hardware contains functionality for controlling multiple devices through one channel, so I need to make sure that I'm closing every device in that channel.   Thanks very much!

0 Kudos
Message 8 of 16
(206 Views)

I tried that, but it does not seem to do anything.  I wonder if I'm using the function incorrectly.  Do you have any sample vi's that show how to use this function correctly?  Also, does the close function apply to a channel as a whole, or do you have to specify a specific device?  My hardware contains functionality for controlling multiple devices through one channel, so I need to make sure that I'm closing every device in that channel.   Thanks very much!

0 Kudos
Message 9 of 16
(203 Views)

"My hardware contains functionality for controlling multiple devices through one channel", but yet you open 2 different COM ports.

 

Basic troubleshooting: Put case 1 and case 3 in series and see if they work. (don't use a stacked sequence)

 

0 Kudos
Message 10 of 16
(198 Views)