LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

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


@jamiva wrote:

If you can see it in NI MAX, highlight your Device/Interface then click “Open VISA Test Panel”. According to your previous post, you are using 9600/8/1/none. Check that the serial settings are correct in the Test Panel then click “Input/Output”. Type your commands in the box and do a “Query” and see what you get back. If you get back old data, just keep hitting “Read” until all data is flushed from the buffer


ICCR-Lab,

Sorry about the confusion earlier. I was in a hurry to post and wasn't too clear. I meant to use this a a diagnostic tool: to see what was happening behind the scene. Sometimes you need to look at the comms data byte-by-byte. A lot of what you were saying was vague and hard to analyze. I was hoping you would post the raw data back to us so we could take a look at it.

 

I'm in a hurry agian. Maybe you could read up on using NI I/O Trace. That may also give you (and us) a little more data to work with to get this problem resolved.

 

0 Kudos
Message 81 of 114
(670 Views)

@jamiva wrote:

@jamiva wrote:

If you can see it in NI MAX, highlight your Device/Interface then click “Open VISA Test Panel”. According to your previous post, you are using 9600/8/1/none. Check that the serial settings are correct in the Test Panel then click “Input/Output”. Type your commands in the box and do a “Query” and see what you get back. If you get back old data, just keep hitting “Read” until all data is flushed from the buffer


ICCR-Lab,

Sorry about the confusion earlier. I was in a hurry to post and wasn't too clear. I meant to use this a a diagnostic tool: to see what was happening behind the scene. Sometimes you need to look at the comms data byte-by-byte. A lot of what you were saying was vague and hard to analyze. I was hoping you would post the raw data back to us so we could take a look at it.

 

I'm in a hurry agian. Maybe you could read up on using NI I/O Trace. That may also give you (and us) a little more data to work with to get this problem resolved.

 


I was in a hurry, too.  My apologies for my terse responses, jamiva.  🙂

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 82 of 114
(662 Views)

I feel you guys are making this all pretty unnecessarily murky. There isn't something like a VISA termination character and a device termination character that are distinct from each other. They should be the same character or the VISA communication won't perform as intended.

And a device uses whatever termination character the developer fell in love with. Smiley Very Happy The most common are <CR> and/or <LF>. I definitely wouldn't say that <CR> is very exceptional. It is the default line end character for Mac systems, while DOS (Windows) usually uses <CR> and <LF> in that order and *nix uses the <LF>. So using <LF> will work well for any device that either uses the *nix or DOS line termination but fall flat for the Mac variant.

Another possibility is the EOT (0x04) or ETX (0x03) character which is often used in (pseudo)-binary protocols. But that is another chapter.

 

And while you can append whatever termination character you want to every string you send, and therefore don't need the VISA feature to do that for you implicitedly it's a very powerful feature of VISA to terminate reads on a specific character.

Reading the manual for this particular device it would seem that except for the # command which is special, all other commands consist of two case insensitive characters and CAN be terminated by a carriage return. If it isn't terminated with a carriage return, the device will sit there and wait a certain amount of time to see if something more arrives and then execute the command anyhow. For me that would mean: Terminate those commands, dammit! Smiley Tongue It doesn't hurt but definitely should speed up the device response, which can be a game changer if you write an application that communicates a lot with this device.

 

All commands except the # command produce a response (which has to be read of course, to clear the serial port buffer) and are terminated by the / character.

Sounds pretty clear, despite the somewhat unusual setup this forms.

 

That all said I have probably read more instrument manuals that claim one thing but where the device does something different, than manuals that were actually describing exactly what the device does. Still it should seem pretty straight forward to debug this device and see how it behaves and where it may behave differently than the manual states, if any.

Rolf Kalbermatter
My Blog
0 Kudos
Message 83 of 114
(644 Views)

thank you very much Rolk,

 

My code as been updated accordingly, and will be tested as soon as I'll receive my new cable...

 

I can't wait to see how full of bug(s) it will be 😛

 

Flo

0 Kudos
Message 84 of 114
(641 Views)

Hello!

 

So, I just received my cable, and managed to connect my pump using a serial port. and guess what? everything is working fine. Only issue is that the switch to run the pump has to be clicked twice to make it work (for some reason I still ignore, the first click will send the value "false" even though I initialize it at false when I prime the controller).

 

Thank you so much !

 

(you'll see me very soon as I'll have to create a controller for an ISCO pump now)

 

Flo

0 Kudos
Message 85 of 114
(617 Views)

My advice: Don't ignore it.  Fix it now.  If it's an issue with an incomplete understanding of LabVIEW coding basics, you risk propagating this issue to all future applications - like the one you are moving onto now.  If it's an issue with an incomplete understanding of instrument communications, this could lead to situations where you lose control of the instrument - something you probably want to avoid.

 

It's best to attack the problem now, while it's still a small one.

 
 
 
Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
Message 86 of 114
(604 Views)

I do agree! 

 

but somehow I haven't find anyone having had this issue so far...

0 Kudos
Message 87 of 114
(595 Views)

We haven't seen code in a while; it's likely to have evolved.  Could you upload the latest version?  Thanks!

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 88 of 114
(591 Views)

here you go  🙂

0 Kudos
Message 89 of 114
(589 Views)

Hang on while I post it to the version conversion board.  😄

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 90 of 114
(585 Views)