Getting VISA Read output format right (hex, ASCII, ???)

[Minions]

Use the Fractional/Exponent String to number instead of Decimal String to Number.

BTW: Sorry for stealing your thunder there Bob..

[Minions]

This is how I would have parsed the data in the output buffer knowing that each response is separated by a carriage return.  If one of the numbers you are reading throws the alignment off from your current code, you might be out of luck.

[M_Williams]

Minions, I tried your implementation but I end up with zeros returned. Is the true condition wired to anything differently?

Edit: I had the wrong file uploaded. 

[RavensFan]

You need to follow the instructions Crossrulz gave you in message #8.  We can't help you figure out if your VI works when we don't have your equipment or any example of what the data looks like.

1. Run your VI.
2. Collect data.
3. Stop it.
4. Go to Edit >> Make current values default.
5. Save VI.
6. Attach it to your message.

Now we'll have your actual data to see how it is structured.  (Typing stuff into a message is not the same thing.)

[M_Williams]

RavensFan: I followed your instructions to the best of my abilities and will attach the associated file. 

Perhaps a higher level explanation of what I'm doing is in order. What I'm trying to do is replicate certain functions of existing software using LabVIEW.

An obsolete automotive smog dynamometer uses an RS-232 interface to communicate with the control computer. The original software package has no capability for logging values (power, torque, speed, etc.) or displaying any graphs. I am building an interface that will use the same communication protocols as the existing software to send data requests, read the responses and log/graph them. As such, I have used COM port logging software to log the typical communications transmitted between the existing control computer/software and the dynamometer (I'll attach this as well). Because it is also fairly inconvenient to test this VI exclusively at dynamometer I am using a virtual serial port program to imitate the dynamometer's responses as recorded in the previous logs. In effect I AM just typing in the previously recorded response into the serial terminal since that is the same value that the VISA read will receive. Perhaps I'm missing something, but I can't understand how the result would be any different if I was communicating with the dynamometer directly. This method has worked to read a string of 0s and 1s from the dyno and turn a series of LEDs on or off as status/warning indicators, but getting numerical values out of the read strings is proving more difficult. I can link in a PDF manual which describes the communication protocols of the dynamometer if it would help. I didn't originally because I felt it would be asking a lot of the people here who are already generous enough to help me, to read through that too.

Eventually I'd like to incorporate a second VISA source to also log from the OBD2 ports, but the dyno logs are the most important part of the project.

Thanks again for all the help!

[RavensFan · Accepted solution]

Okay.  I'll agree with Bob.  Your instrument sends a very odd implementation of data.  It is sending ascii characters that are converted to a hex byte implementation of those characters converted to the the ascii characters in pairs separated by spaces.  Just way too many conversion.

You need to start with Bob's code to convert the hex hex space hex hex space to actual hex bytes for the ASCII characters, then Minions code to break that resulting string into numeric data.

[Minions]

My mistake.  I took the line that the OP had posted and brought that in as an input to my vi that was set to HEX display on its input.  It worked perfectly.  Didn't realize that the data posted wasn't quite what it seemed. 

Next time, show your vi with the results displayed in HEX and Normal to get your point across.  A picture is worth a thousand words.

[crossrulz]

---

@Minions wrote:

Didn't realize that the data posted wasn't quite what it seemed.

---

That is why I kept asking for clarification on what the data actually was.  I have seen way too much confusion between the data being ASCII vs HEX.  And this was the super weird one that decided to turn ASCII into HEX into ASCII and write that.  Personally, I would have shipped the instrument back, demand a full refund, and buy from their competitor if I had discovered that was the protocol.

[Ben]

---

@crossrulz wrote:

---

@Minions wrote:

Didn't realize that the data posted wasn't quite what it seemed.

---

That is why I kept asking for clarification on what the data actually was.  I have seen way too much confusion between the data being ASCII vs HEX.  And this was the super weird one that decided to turn ASCII into HEX into ASCII and write that.  Personally, I would have shipped the instrument back, demand a full refund, and buy from their competitor if I had discovered that was the protocol.

---

Was that machine used ina old Ford Dealership?

DEC is no longer around so the warranty period is long gone. My buddy used to fix PDP-8s that just may have been the original machine.

Ben

[M_Williams]

Thanks for all the help everyone! I was able use the file from Ravensfan in my serial communication simulation and return correct values. I'll try it on the real thing tomorrow. The protocol this machine uses certainly didn't make sense to me, but I'm relatively new to serial comms. I'm glad there is a clean solution for this in LabVIEW.

I think my biggest problem was struggling with it for so long instead of coming here first. I'm sure I'll have more q's in the future and I'll try to post pics where warranted. 

Btw Ben, the dyno was bought at auction by a mechanic who only needed the computer and sold the rollers/brake separately. Luckily I found a copy of the software (on floppy no less) and was able to test with that... Once I got a hold of a 32 bit machine to run it on.