Remote Command/ACK Response

[Steve.Briggs]

Hey Adam,

I've done everything I could do with and without the timeout value.  Making it very small (10 ms), very large (30 seconds), and making it nothing at all (0 seconds) all result in the same thing.  Inconsistency with my scans; sometimes it will work, sometimes it won't scan anything.

I'm almost certain it has come down to the byte count I am reading, or not being able to send the ACK response (ASCII code 6, control-F) at the end of each line quick enough in order to proceed to the next.  My scans should be going from 465nm - 655 nm, but the scan procedure is interrupted by the error after only 40nm have scanned.  Concerning the byte count...when I read the Bytes at Serial Port it always gives me a value of 0, but I know there is data being sent because the spectrophotometer is scanning simultaneously and I always see 2 or 3 lines of data coming off of the VISA Read.  So instead I simply have a numeric constant of 100 bytes to count on the VISA Read.

What puzzles and frustrates me most is that I didn't change anything in the write/read procedure from the vi that Dennis helped me with, which worked fine since January 11th, but now it does not want to cooperate .

Thanks Adam

[Adam W]

Hey Steve,

Just tossing out some other ideas:  what version of VISA are you using?  Would it be possible to try updating the driver?  You said that it stopped working one day; did anything change in your setup or development machine that might affect your code at all?  Do your port settings match in MAX and Device manager?

Could something on your test unit be causing anything this kind of behavior?

Just trying to think of things we may have overlooked.

Adam W
Applications Engineering
National Instruments

[napview]

Dang it! Put in some words and waited a short while then page time out happened so all the typing was gone.

Anyway I try to re type some of them.

From what you said (or heard) and your developer said: "I am sending a ?SCU (scan) command to record transmittance from a set wavelength and the data comes up a line at a time and I have to reply to each line with an ACK response (ASCII - 6, control - F).  I also have to detect the ##END= line to know when the data set ends." and "When I talked to one of the creators of the spectrophotometer I am using he said..."Note that data comes up a line at a time and each line has to be ACK'd in a few seconds or it times out, approximately less than 8 seconds." ==> Write/readback/wr back for each command with ACK (1).

Also from what you actually saw when running the VIs :"I then took a look at the bytes at port property node, and have it read the bytes when they are greater than 0.  This worked for one line, when the byte count was 17, but then resulted in byte counts of 0 there after, so nothing ever progressed.

I then put a small delay in my loop where I read and write the ack command (hex "06"), but it gave me an instant error 1073807339 for timeout rather than occurring after I read one line of data, which usually happens." ==> This falls in line with (1). The readback in the 2nd loop worked for the last write command and after that 0 bytes are at the port. It would be interesting of what is read there. Is it corresponded to the last write command or whichever one that is written?

They seemed to be contradictory so I am assuming that you are missing some info from the developer which is after EACH write then readback and if there is any byte then write back with "/6" for ACK, then continue on with the next write and read back until "END" is detected. The reason behind this logic is that the serial port protocol usually works for one on one communication. It did not make a whole lot of sense when having to write a bunch of commands then read back only ONCE.

If you confirm this assumption is true then try the attached vi (modified):smileyhappy:.

This took me more than 1 hour of work including the re-type but I am glad to help anyway.

[napview]

The previous VI is not working on actual port so try this one.

[Steve.Briggs]

Adam,

Nothing had changed, that's why I was so frustrated with the errors I was receiving.  However, I have a theory to which I believe why my program/executable is working now.  Of course the original executable worked on the computer that I created the original vi on...but what's the point of an executable on a computer that has LabVIEW fully installed.  So I saved the executable to another computer which had LabVIEW RunTime Engine 7.1 on it and VISA 3.3.1.  The executable would work, but it was hit or miss.  Sometimes it would work perfectly, sometimes it wouldn't work at all.  I then thought that maybe it wasn't able to write/read quick enough, the computer was very old and had a very slow processor.  I installed the RunTime Engine and updated the VISA drivers on to my office computer and the executable has yet to fail on me.  I think this may have something to do with my processor speed.  The ACK response must be sent to the spectrophotometer in under 8 seconds, perhaps it wasn't getting there fast enough on the other computers.

Napview,

I took a look at your vi and it does work .  For the time being though, I'm not having any problems.  If something should happen to come up in the future, I'll be sure to incorporate the ways behind your vi into my vi. 

Thanks for the help!

[napview]

Glad to hear that

[Steve.Briggs]

For some reason whenever I try to open your vi now it redirects me to the LabVIEW welcome screen..

Oh well, a new problem and idea have arisen.

I have discovered a way to always have my scan complete.  By simply inputting several ack commands after my scan command into the array I am guaranteed to have my scan finish.  However, I get 0 bytes at the serial port, and when I have a hard setting of 100 bytes to read, I timeout.  I know the solution to my problem may not in fact be a clear cut solution, but I'm taking what I can get at this moment...which is a complete scan, just nothing being read.

Thanks for any help,