VISA and READ function - Problem linked to the bytes at port

[Omar_II]

---

If i recall correctly, labview wont allow for multiple termination characters? ...

---

Bill,

Well you can if you open duplicate sessions, one for writing and one for reading and then assign different termination characters. Then use only one for writing and only the other for reading.

I have never done this but it should work.

[billko]

---

@Omar_II wrote:

---

If i recall correctly, labview wont allow for multiple termination characters? ...

---

Bill,

Well you can if you open duplicate sessions, one for writing and one for reading and then assign different termination characters. Then use only one for writing and only the other for reading.

I have never done this but it should work.

---

Probably easier just to add the outgoing termination onto the end of the message.  😉

[Flo-w]

Hi everyone,

I just came back from a 3 days long week end 🙂 Which explains the poor amount of reply !

I didn't know about that clean-up tool, so I used it, and that's kinda magic to my opinion!

As requested, here is my VI. 

Quick reminder: I had problem in updating some variables. Update: so, I've cleaned my code, and updated it according to your recommendations (no more flush thing, I've removed the Instr. , etc). Now, what happens is:

- first time I run the VI: everythging is nicely updated, the code seems to work

- first update of the values (for ex. I want to update my flowrate..): that works as well.

- I close my VI, and re-open it: my numerical boxes should be updated , and it's not working. Maybe it has to do with the communication between labview and the serial port, which somehow is not released ? but the "CS" command returns no information. (just a "OK/" instead of a more complex "OK,12.00,10000,0000,psi,0,0,0/"

😞

Flo

[Flo-w]

Sorry for the double post, but I can't edit my previous one.

I've spotted a wierd behavior: I have put textboxes after each READ functions to see what the pump sends back to the VI.

When I prime the pump (timeout event) sometimes it works, sometimes I've got error 85 from one of the two scan from strings functions. Even weirder, If I update a vairable (set event case), then close & re-open the VI, the command "CS" is ignored and I sometimes READ on my string indicator the response of another command (from one of the WRITE functions from the Set event case). I think the Error 85 comes from that..

is there some sort of memory buffer somewhere that I should dump all the time ??

Edit: there is DEFINITELY some sort of memory kept somewhere. The string sent back by the pump was a command I've sent an hour ago  

I am so lost!

Flo

[RavensFan]

I don't understand the way you've constructed your VI.

You start with a timeout of zero and the timeout event case will immediately run sending a CS (should you have a termination cahracter there?) then to set the timeout value to -1, never to be changed again.

All of your other event cases just send commands and never do a VISA Read again.

Your code to set some leading zeroes on numbers is a Rube Goldberg.  You can do all of that with just one function.

 

[Flo-w]

 the timeout event is made by following this NI suggestion:

http://digital.ni.com/public.nsf/allkb/2F5A98A36556FCE5862572A8006A8726

[RavensFan]

That is fine when you want something to happen one time at application start like it says.

But you are failing to ever read anything from the serial port again after that because that is the only event where you have a VISA Read.

[Flo-w]

I assumed that the while loop was then going on and on. Is it not what is happening? 

Basically, when I run my software, timeout event is being executed. then the VI waits for me to do any other actions.

[RavensFan]

Yes.  The loop keeps iterating.  The event structure waits for  an event to happen, executes that event case and iterates again waiting at the event structure in the next iteration.   After the first iteraiton, you set the shift register to -1 which means the timeout event is set to wait forever.

Try running your code with highlight execution to see how it behaves. 

Then I would recommend looking at the online LabVIEW tutorials
LabVIEW Introduction Course - Three Hours
LabVIEW Introduction Course - Six Hours

[Flo-w]

Well, as I said, it behaves well:

- the first timeout event is triggered (which is the primer stuff I want to do every time I run the app)

- then the code waits for any other events to happen (switch switched, button clicked, etc..)

and here again, it bahaves! For some reason the code keeps in memory wierd commands.