Help with parallel execution

[coolhandLV7]

I have (2) operations that need to execute at the same time, one of the operations is serial communication to a motion controller the other is to execute a VI that collects and saves data (DAQ).  See below.  I have the VI's running independent and in parallel with the wiring, however the serial comm (ie no motion occurs) when the other VI is busy.  I've searched the forums and have found several examples that would suggested my setup is good, but it's not working.

I've attached a picture of the SateMachine i'm using that shows the serial communication and DAQ VI.

Let me know if i'm missing something.

[billko]

Yeah.  You're missing uploading the actual code so we can see what's behind that (evil) stacked sequence structure (SSS).  Fortunately, I can see what is going on here.

Although it's true they are executing in parallel, they are in the same frame of the (evil) SSS, and each subVI will only execute once per frame execution.  Even if you got rid of the (evil) SSS, a subVI can only execute once per loop iteration.  Think LabVIEW DATAFLOW basics.  You need to have them in separate loops and structures.  Look at Producer/Consumer design pattern.

[coolhandLV7]

Ok i've attached the VI.  All the (SSS) does is a wait command in Seq1, then move to execute the actions seen in Seq2.

Anyway, i thought about producer/consumer but i don't think it applies to this example, i'm just trying to Move something and measure it at the same time.  The two actions are not linked other than to tell them both to "GO" at the same time.

[mcduff]

You have an interesting way of communicating with your serial instrument. Check your manual and see if your instrument sends a termination character and use that instead of bytes at the port.

Just a guess here...

LabVIEW can execute things in parallel but you cannot control the order of operations or ensure that they operate at the same time. Your serial port loop that check the bytes at the port is greedy, it is spinning as fast as possible, which is maybe tying up your resources. Try putting a 1 ms wait in the loop and see if that helps. In the long term, I suggest you rethink your communication protocol.

mcduff

[coolhandLV7]

Makes sense.  They call it a terminator it's the CARRIAGE RETURN, at the end of each command.  I guess my next question is do i even need the SERIAL READ VI at all?

[mcduff]

If you send a query to the instrument and it sends a response you want to read it, even if you do nothing with the response.

One way to set up communication is to use the termination character of the REPSONSE and set up the VISA read with a number of bytes longer than your typical response and a timeout value. When the termination character is set VISA read will stop automatically when it reads that character. This usually works really well. The exceptions are when you are reading binary data or if your response contains multiple lines that are separated by a carriage return. In those cases you can use Bytes at port, although when I do, I normally check every 50 ms, serial is slow.

mcduff

[billko]

---

@coolhandLV7 wrote:

Ok i've attached the VI.  All the (SSS) does is a wait command in Seq1, then move to execute the actions seen in Seq2.

Anyway, i thought about producer/consumer but i don't think it applies to this example, i'm just trying to Move something and measure it at the same time.  The two actions are not linked other than to tell them both to "GO" at the same time.

---

I apologize for not being able to read.  Ugh, I re-read your original post, and indeed I see that there is no relationship of the code other than they are happening at the same time, therefore consumer/producer is NOT applicable here.  Sorry to mislead you.  😞

[coolhandLV7]

---

@mcduff wrote:

If you send a query to the instrument and it sends a response you want to read it, even if you do nothing with the response.

One way to set up communication is to use the termination character of the REPSONSE and set up the VISA read with a number of bytes longer than your typical response and a timeout value. When the termination character is set VISA read will stop automatically when it reads that character. This usually works really well. The exceptions are when you are reading binary data or if your response contains multiple lines that are separated by a carriage return. In those cases you can use Bytes at port, although when I do, I normally check every 50 ms, serial is slow.

mcduff

---

Going to try this, since the TRIGGER state only sends one command string with one TERMINATOR carriage return this should allow me to remove the While loop around the SERIAL READ.

I also found these (2) examples, which honestly Newport overcooks these VI's, but i can set the INIT with TERMINATOR called out and use the SerialRead example, neither of which contain a While loop. 

[coolhandLV7]

One other thing I've ran across was calling a Reference VI, i have never used this technique would calling the LJV VI from the TRIGGER state permit parallel execution?  

[mcduff · Accepted solution]

I think that is the way to go.

Newport Read VI includes a write, and a read along with a flush buffer? Note sure if that needed always, it also includes some sort of message logger or error parser.

You maybe can set up something as simple as something like this

Try some simple commands and responses and you can whittle down your VIs.

mcduff