I'm fairly competent in labview and this will be my second time writing my own driver (although the first was more straight foward). The provided software from the manufacturer looks like it was written in labview so I asked if they could help me with some code and here's what was provided:
HD300 COMMUNICATION PROTOCOL Download protocol: 0 1 2 3 4 5 6 7 8 9 10 0xff 0xaa 0x55 k data X1 X2 X3 checksum 0xff (short) Checksum = k + data + X1 + X2 + X3 Request to send the command: k = 0x63 data = 0x63 (X1，X2，X3 is arbitrary value) Data table：k = ‘k’ MAX/MIN(U) AVG HOLD(U) IRT UNIT MAX/MIN(D) HOLD(D) AREA POWER Click 10 20 30 40 60 50 70 80 Double click 11 44 66 IRT key click: i = ‘i’ 0 1 2 3 4 5 6 7 8 9 10 0xff 0xaa 0x55 i 10 X1 X2 X3 checksum 0xff Upload protocol: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 a d j g F1 F2 F3 F4 F5 Vel_mode Ambient temperature Air speed 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 IR temperature DISP1 DISP2 DISP3 CFM AREA 38 39 40 41 42 43 44 45 46 47 48 49 CMM AREA MULAVG COUNT AREA INDEX 0xff g 0xff g checksum F1: 7 6 5 4 3 2 1 0 F(U) C(U) MAX(U) REC(U) F2: 7 6 5 4 3 2 1 0 FLOW VEL TYPE K IR TEMP HOLD(D) MIN(D) MAX(D) REC(D) F3: 7 6 5 4 3 2 1 0 C(D) AREA PC-LINK knots X100 X10 AVG F4: 7 6 5 4 3 2 1 0 km/h Ft/min m/s CMM CFM ft2 F(D) m2 F5: 7 6 5 4 3 2 1 0 MPH POWER HOLD(U) MIN(U) else vel_mode: 0 1 2 3 4 5 6 m_s ft/min km/ h mph knots CFM CMM
I'm not exactly sure what I'm supposed to do with this, it wasn't at all like what I was working with last time.
I couldn't see if there's a way to edit posts, so I'll just add a bit more of relavent info. The previous time I wrote a driver I used the Instrument I/O Assistant and used serial commands for the device as refrence. Not even sure what the above table is.
It's the list of serial commands. It appears you have to send/receive data as a series of hex bytes (prefix, data, checksum, suffix). With the Byte Array to String, you can create the command and pass it to the VISA Write function. There have been numerous posts on using hex data and checksum calculations.
I will never use the Instrument I/O Assistant as it does not create a 'proper' instrument driver. I have no idea if it can be used in this situation.
Well, I've since rewritten my previous driver properly using VISA to try and understand better, but this protocol is substancially more complicated than my previous one.
I'm not sure if I should be writing the upload protocol or the download protocol.
It looks like the IRT key click (infrared thermometer) command is given as an example, except byte 3 which is still defined as 'i' which I don't understand.
And X1,X2,X3 can be any value for the purposes of the checksum?
I've added a picture of the VI as I'm working on it.
You may have to write both upload and download. I have not studied it in detail, but if you need to send and receive, then you will need both. And, if the send commands will change based on some user option, then you will need to dynamically create the checksum.
For your testing purposes, I think it is easier to just start with a U8 byte array instead of all of those conversion functions (which are incorrect as I8) and the build array but in the long run, you will probably need both.
If the manufacturer's code is written in LabVIEW then perhaps they will share the actual LabVIEW source code that they use for their application? I'd try pushing on them a little bit more as you're essentially just going to be redeveloping what they've already done if their code truly is developed in LabVIEW.
If only...I asked if there was anything else they could provide, source code, examples, documentation. That's all I got. They assume you either know how to use the above or just use their software.
The provided software gives an interactive diagram of the device where you can press any button and it works on the diagram and on the device. So, I'm trying to simply send the command to use the built in Infrared Thermometer (it beeps) and not even recieve data. But I don't think I'm coming up with the proper command, haven't managed any progress yet.
Have you tried using a serial port sniffer such as portmon from Microsoft. If their code was truly written in LabVIEW, you can used NI-Spy/NI-Trace to capture the commands.
Thanks for the advice for sniffing with Portmon, it took some resource hacking to get it to work properly (apparently a known issue, but the dev seems to have abandoned it).
I used it in conjunction with the included software (built in VC++ considering the dll I found in there, not Labview ) and got way more information than I bargained for. I stripped out all the commands that I think were simply from the serial to usb.
Additionally I stripped out what I believe to be the ACK writes to the device (length 1: 1) so as to better compare each read.
As the log name suggests, the only thing I wanted to get out of this was to read the ambient temperature as it appeared on the device and software. According to the protocol above, this should appear between the 10-13 bits, but there is an additional bit AA at the beginning so I believe it's actually 11-14th bits. Taking the first reading, C2 F9 B2 41, this number is nowhere near 72.4F in decimal, so I'm not sure what's going on. The protocol has a way of knowing if it is set to F or C (the F1 bit at 4+1 offset, which reads as 08, not on the protocol), so I don't see why it would be in kelvin or such and the conversion would be software side.
The only things I've managed to confirm from the protocol and the software is that Vel_mode is set to ft/min = 1 as in bit 9+1offset. All other fields seem to be giving values that aren't listed on the documentation.
At this point, it couldn't hurt to try and ask the manufacturer for help again. I know it's been difficult, but you've got more information on the port communication and a more specific problem description, so hopefully they'll be a bit more generous.