viWriteAsync translate

[slucas]

hello one and all,

i have an interesting problem.  i am trying to reverse engineer the communication protocols to a device.  i have the software to control it and i can trace the entire communication through NI I/O Trace.  i have a line that looks like:

975. viWriteAsync (ASRL3::INSTR (0x028A08A8), "........", 8, 0x040400DC)
Process ID: 0x00000F74 Thread ID: 0x0000038C
Start Time: 06:51:38.590 Call Duration 00:00:00.000
Status: 0 (VI_SUCCESS)

WITH THE DETAIL INPUT TAB SAYING:

vi ASRL3::INSTR (0x028A08A8)

&buf ------ 0x07041520

cnt -------- 8 (0x8)

&jobId --- 0x0671FC94

WITH THE DETAIL OUTPUT TAB SAYING:

*jobId ---- 0x040400DC

function returned: 0 (VI_SUCCESS)

AND DETAIL BUFFER TAB SAYING:

Buffer Contents:

00000000: 01 03 00 04 00 02 85 CA  ........

Contents of parameter: buf

i want to duplicate this exactly in LabView using VISA.  i am guessing that i would "VISA Write.vi", but how would i properly pass the above input tab information to it properly and exactly?

thank you in advance and have a great day.  lucas 

[Chris-G]

I would check out a couple of the examples that ship with LV. The Basic Serial Write and Read.vi shows the basic layout for writing to/reading from serial using the VISA driver. The Advanced Serial Write and Read.vi shows further functionality to allow control of things like the input buffer.

Also, depending on the instrument you are communicating with, there is a chance that there are drivers written for LV for that device. Go to Help -> Find Instrument Drivers... in LV to see if any are available for your device.

In general, it's difficult to say what exactly is being communicated between the device and its software without knowing more about the device itself. Are there properties or tools in the software to allow you to find out the settings associated with the serial communication? If so, try matching those settings in LV.

Chris G

[JÞB]

Portmon

is actually a much better tool for reverse angineering a com protocol.  That being said. The Better way to do this is to get ahold of the manual for the device from the device manufacturer.

[MoReese]

Jeff,

Thanks for the tool.

[slucas]

yes, using both portmon and ni trace i have been able to track the write/read hex based command structure and data flow between the remote device and the computer.  writing simple VIs i have been able to verify my finds and i am slowly getting good control over the device.

i started out looking for drivers under ni, the internet, and begged the manufacturer for the command structure.  they were proprietary all the way and no labview drivers exist anywhere for the device.  i think i am going to release my drivers for free to help others with the same device, probably also under ni instrument drivers.  

are there any legal ramifications if i release the drivers without the manufacturer's knowledge or expressed written permission?  thanx for all of your help and have a great week.

lucas

[MoReese]

Well, I'm no patent lawyer, but I would say it's your source code that works with the device.  The mfg has nothing to do with that.  If you want to release your code to the community, that's your prerogative.  But again, I'm no lawyer.

[JÞB]

---

@slucas wrote:

yes, using both portmon and ni trace i have been able to track the write/read hex based command structure and data flow between the remote device and the computer.  writing simple VIs i have been able to verify my finds and i am slowly getting good control over the device.

i started out looking for drivers under ni, the internet, and begged the manufacturer for the command structure.  they were proprietary all the way and no labview drivers exist anywhere for the device.  i think i am going to release my drivers for free to help others with the same device, probably also under ni instrument drivers.  

are there any legal ramifications if i release the drivers without the manufacturer's knowledge or expressed written permission?  thanx for all of your help and have a great week.

lucas

---

The only issue I see is that the driver will not be able to be submitted "for certification" since the package for cert requires a copy of the manual.

The mfg should know better- I have run into this before and declined to purchase instrumentrs that have no command documentation.  the Time required to reverse engineer the comms is usually more costly than a substitute device with documentation.