Trying to use a USB serial link with a modbus device

[Ted_Jackson2112]

Hi.  I have a LeddarTech LIDAR device that is attached to my Windows pc via a USB port over an RS-485 serial connection and uses the modbus RTU protocol.  The device works fine with its example software and I can view the communication back and forth with Wireshark.  I'm hoping to duplicate the serial communications with the device to configure and retrieve its measurements via a LabView vi and ultimately to emulate the serial communications via a simpler device like an Arduino.  I have the NI Modbus.llb for LabView 7.1 (the LabView version that I'm stuck with, so I can't even view VIs saved in more recent LabView versions).  And of course I have the standard VISA communications VIs that come with LabView.  The port shows up in Measurement and Automation Explorer as ASRL::INSTR "COM8" and it does Validate.  However, I've so far been unable to write a VI that will even show any evidence of communicating on the serial line in Wireshark.  Attached is the latest attempt.

From the 'NI Modbus.llb', I've tried working with 'MB Serial Example Master.vi' with no luck.  I've tried working with the raw Instrument I/O -> VISA VIs with no luck.  From Find Examples, I've tried the Advanced and Basic Serial Write and Read examples with no luck and the NI RS-485 Transceiver Control example with no luck.  I'm pulling my hair out trying to figure out what to do.  Can anyone get me started?  From any of these starting points, can anyone tell me the best one with which to begin?  Thanks.

[cbutcher]

---

@Ted_Jackson2112 wrote:

The port shows up in Measurement and Automation Explorer as ASRL::INSTR "COM8" and it does Validate.  However, I've so far been unable to write a VI that will even show any evidence of communicating on the serial line in Wireshark. 

---

Just a quick check, but... if Wireshark is "opening" the port, it might be blocking LabVIEW from opening the port.

---

@Ted_Jackson2112 wrote:

Attached is the latest attempt.

---

Seems you might have missed it 😉

[Ted_Jackson2112]

Yep, I did forget to attach anything.  Wireshark.png shows the bytes from the first query/connect frame to the unit from the example (HOST) after running the LeddarTech example.  All frames, by the way, have identical initial bytes, which I assume are necessary for framing serial coms.

I'll start with 'MB Serial Example' again.  Nothing shows in Wireshark after running 'MB Serial Example'.  To address cbutcher's point, I close Wireshark and the VI, then reopen the VI, run it and the output is the same (nothing in the Input Register display), but I'm not sure I'd expect anything in the Input Register display.  I see no reason to believe that Wireshark would interfere with the VI's function.  It doesn't interfere with the LeddarTech example which produced the Wireshark data.  And without it, I learn next to nothing.  Any suggestions?  More info needed?  The first response from the unit's URB_CONTROL frame (Frame 2) returns the device's basic config data.  I've studied the Modbus specs.  I've studied the LeddarTech unit specs.  Those mention:

"The Detections parameter is the maximum number of detections to output
in Modbus data transfers (Get Detections – function code 0x41)"  

"Report server ID (function code 0x11)"

"Read input register (function code 0x4)"

I think I see the 0x11 function code in the first response frame from the unit (Frame 2 - bytes not shown) just after the (nearly) identical bytes initiating all frames.  So I tried replacing the function code with 0x11 in subVI 'MB Serial Master Query Read Holding Registers (poly)' which in turn calls 'MB Serial Master Query'.  No luck - still nothing in Wireshark nor the Holding Registers VI indicator.  Unfortunately LeddarTech hides the actual goings on in whatever generates the first frame and response in a pre compiled library, so I'm blind to that, or otherwise I'd probably be able to figure it out.

[Ted_Jackson2112]

Yep, I forgot the attachment.  The Wireshark log of the LeddarTech example interaction with the unit is attached, with the first query/connect frame (Frame 1) bytes detailed (Wireshark.png).  All frames have the first several bytes nearly identical by the way, which I assume are 'framing' bytes necessary for serial coms.

I'm trying again with the 'MB Serial Example Master' VI.  Per cbutcher's note, I tried running the VI with Wireshark not running, and the 'Input Registers' is empty in both cases.  With Wireshark running, its log is empty as well.  You'll notice from 'LeddarTech Example Output.png' and the 'MB Serial Example Master' diagram that I've matched the available serial connection config data from the LeddarTech example.

I've studied the Modbus specs.  I've studied the LeddarTech unit specs and that includes:

The Detections parameter is the maximum number of detections to output
in Modbus data transfers (Get Detections – function code 0x41)...

Report server ID (function code 0x11)
This function returns information on the sensor in the following format...

Get detections (function code 0x41)
This function returns the detections in the following format...

Frame 2 from Wireshark (see Wireshark Frame 2.png) shows the unit's first response, which after the initial bytes 'preamble' appears to show the 0x11 function code.  So, I tried replacing the function code in 'MB Serial Example Master' with 0x11.  No luck.  Nothing in Wireshark.  Nothing in the Input Registers indicator.  Not sure how to proceed.

[K C]

Hi,

Looking at the the bottom list in 'Wireshark Frame 2.png' I cannot detect any ModBus frames.

Are you sure it is a ModBus device ?

Does the device support the ModBus Loopback command ?

Is it a ModBus RTU device and not a ModBus ASCCI device ?

Kees

[Ted_Jackson2112]

Sorry for the reply semi-duplicate, cbutcher.

Hi Kees.  How does one detect MODBUS frames?  I see URB_CONTROL frames and URB_BULK frames and I'm pretty clueless about those too.  Hope there's a serial coms guru about or that can point me to some good ref material.  It's certainly a MODBUS capable device, but they're a bit ambiguous in that they include a 'Connect to M16 USB' option and a 'Connect to M16 Modbus' option.  I've only been able to get 'Connect to M16 USB' to work yet, so perhaps Modbus isn't involved after all.  I don't know about the loopback command, but could try it.  The Leddartech literature discusses both ModBus RTU and ascii. It's ambiguous (see attached).  Those French (Canadians heehee - no offense) closeted up the details of the actual connection code in a proprietary DLL, otherwise I might be able to figure it out myself.  Thanks.

[Ted_Jackson2112]

Wow.  OK, if anyone can just show me why my ole rusty, trusty National Instruments LabView software won't send a single byte out through the serial port via that USB port using any of the VIs mentioned as a starting point (or another of your own suggestion), since it's proven to be possible, then I'll consider my question answered.  Anyone?

[Ted_Jackson2112]

Uh... I know I'm in a no-win situation if the silence is about the 'Those French' remark.  My boss and colleague for several years was a French PhD and a good friend.  The remark was pure silliness and was intended in the strictest Steve Martin / Monte Python sense.  I wear my sense of humor on my shirt sleeve.  Oh well...

[K C]

Hi Ted,

Cannot always find the the time to react......

In the manual is stated: 'The RS-485 port on the Evaluation Kit uses the Modbus protocol for the RTU
transmission mode only.'

So for me it is clear; it is a ModBus RTU device.

How to detect ModBus frames in bulk data you ask.My first reaction could be: 'Just look at it'

But you know what you should see. If you worked long enough with ModBus you will recognise the the ModBus frames in a HEX dump.

To get thing working could try the following:

Start the example vi: 'Continuous Serail Write and Read.vi'

Set the communication parameters to the correct values

Switch both Booleans (End Read and End Write) to false (off)

Set both 'Command' and 'Response'  to HEX display

Set return count to 100 (for now)

Enter the command: 0111 C02C   (0x01 is slave address, 0x11 is the command and 0xC02C is the CRC)

Run the VI and Write and read. You cloud change the VI to write and read only once.

The return count is not clear. If the device response in a normal way I would expect 156 bytes in the return message.

Lets see if this works 

Kees