serial modbus questions

[JeffOverton]

Hey gang, I have what may be some in depth Modbus questions.  I've attached an llb that should open a COM port, and query Modbus address 2 for some holding registers (particularly 10, beginning at 5002).  I'm getting absolutely zero response, and this is across four or five functions and several different attempts at figuring out what the right way to actually transmit the data is.  As it stands, I'm taking a bunch of U8s and converting them to a big hex string and dumping that out at Modbus.  Is that right?

Also, I tried looking at the NI Modbus library, but it looks like it was written by cretins, and I don't like wading through stacked sequences.

Also also, the device I'm trying to communicate with (a Micro Motion Coriolis flowmeter) apparently has serial autodetect capabilities, so the serial config doesn't matter, and ASCII Modbus is enabled on the device.

Thanks in advance, everybody!

[RavensFan]

You don't have any wait time between your serial write and read.  You haven't provided any time for the Modbus device to turn around the message.  You write the command, immediately return the number of bytes at the port (probably still 0)  read those bytes, then close the port.  You may want a couple hundred millisecond wait statement in there.

I've used the Modbus library successfully on a few different projects.  I agree that those stacked sequences are horrible.  I've noticed a lot of 3rd party driver VI's love stacked sequences.  I guess it is a carryover from older versions of LabVIEW?  It definitely goes against the latest standards of the LabVIEW style guide.

Message Edited by Ravens Fan on 11-19-2008 03:34 PM

[JeffOverton]

Wow, that long?  Thanks, that's worth knowing.

Also, before it was an immediate Read Bytes at Port -> Serial Read, it was a Serial Read (1 byte) in a while loop set to stop on error.  It was timing out after 10 seconds or so.

edit - but is the command is formatted properly and sent properly to be caught by the device?  That was my main concern: whether I can just send the hex commands or if I actually had to format the the string into the ascii values.

Message Edited by JeffOverton on 11-19-2008 03:38 PM

[RavensFan]

---

JeffOverton wrote:

Wow, that long?  Thanks, that's worth knowing.

Also, before it was an immediate Read Bytes at Port -> Serial Read, it was a Serial Read (1 byte) in a while loop set to stop on error.  It was timing out after 10 seconds or so.

edit - but is the command is formatted properly and sent properly to be caught by the device?  That was my main concern: whether I can just send the hex commands or if I actually had to format the the string into the ascii values.

Message Edited by JeffOverton on 11-19-2008 03:38 PM

---

It may not need to be 200 msec, but that is a typical safe number I've used and I think I've seen recommended in other threads.  With no wait, the read is being requested in just a msec or two, or maybe not even that, and I'm pretty sure that would just not be enough time.

I didn't take a close look at how you were generating the ASCII string.  Honestly, I haven't used Modbus ASCII before, just ModBUS RTU, so I'm not an expert in that aspect.  I was just looking at the overall main program and the basic format of your Modbus command string.

Looking more closely now at your Generate ASCII string VI, one thing I notice now is your final concatenation.  It looks like you are appending the carriage return line feed.  But your \r\n string constant is in normal display rather than \ display.  So you are actually appending the characters \ and r and \ and n rather than a carriage return (ASCII 13) and line feed (ASCII 10).  Maybe that is the problem.

[RobCole]

I would take a good look at the device. We have 2 different modbus devices here that require CRC bytes at the end of the strings and both of them calculate the CRC using different methods. I know - it shouldn't be that way, but it is.

Do you have a communication protocol document for the device?

Unfortunately, I can not put our Modbus VIs on here as our company considers them proprietary (we developed our own).

     Rob

[RavensFan]

Jeff,

For you or whoever else might read this thread in the future, if you haven't found these yet, the Modbus specs are good to read.

http://www.modbus.org/specs.php

[JeffOverton]

Thanks guys.  If I used the actual Carriage Return and Line Feed primitives, would that be the same as the string being in \ display?  I tried using those before I saw an example with \r\n, but I have no idea what other variables I had changed.  Also, ASCII modbus needs an LRC, not a CRC.

As to RTU vs. ASCII, the device is capable of both.  Would it make more sense to try RTU?

[RavensFan]

Yes, the carriage return and line feed primitives would work just like \r\n as a string constant when they appear in \codes view.

Theoretically, if the device uses both, then either should work fine.  You are correct that it uses LRC for ASCII mode and CRC for RTU mode.  It is always a possibility even though it shouldn't be like Rob said that it uses a different algorithm.

My experience has all been with RTU, so I am most comfortable with that.  There is one reason I can think of to use RTU over ASCII.  It requires less bytes.  One byte represents all the values between 0 and 255 for RTU.  For ASCII, one byte needs two character bytes to represent 0-9,A-F to represent a byte.  The advantages of ASCII is that it would be more human readable if you were snooping on the data stream (no unprintable characters to worry about).  And perhaps if you were trying to run the data through some old telnet connection that only allowed 7 data bits, ASCII would be better.