Sign in to follow this  
ccdubs

DF as MODBUS Slave

Recommended Posts

Hi all,

I can't seem to get my DF MODBUS slave device to work. I have had it working in the past but for the life of me I can't get it working again. I have confirmed that the data is being received on the correct port and it looks correct.

Can you please confirm what channel fields I need to fill in? The DF slave has been given an address of 2 and the master device is sending a single integer with no address offset.

Many thanks.

Share this post


Link to post
Share on other sites

Just the Modbus Slave # column. I presume you are setting the ModbusAddress variable to 2 in a startup script. It will default to 1 otherwise as it doesn't persist with the document. You might just see if an address of 1 works but not 2.

Share this post


Link to post
Share on other sites

Yes I am setting the MODBUS address variable to 2. I found by slowing the com port down to 9600 I am at least getting a TX response from DF, but I am not able to read the number updating in the channel.

The device is a TriLogi PLC which uses 40000 notation, do I need to set an additional parameter to account for this.

FYI, even at 9600 baud I am sometimes seeing the MODBUS command comming through 3 times (in one row in the comm monitor window). At 38400 baud I was seeing this every transmission.

Share this post


Link to post
Share on other sites

Hmm, weird. Well, I really would need to see a screenshot of the monitor to see what is happening. Either things are getting garbled, or the trilogi is requesting the wrong tags. Also, please specify what you have the Modbus Slave # set to for the channels you are querying so I can make sure the trilogi is querying the right channel.

Share this post


Link to post
Share on other sites

I am having a similar problem. DAQFactory responds as modbus slave when the baud rate is 9600, but it does NOT respond at 19200, even after initializing the port. I am sending screen shots of channel table, and port traffic.

Please help :o

Thanks.

post-915-1226941255_thumb.jpg

post-915-1226941278_thumb.jpg

post-915-1226941293_thumb.jpg

Share this post


Link to post
Share on other sites

It has nothing to do with baud rate. In the 9600 one you are requesting tag #18, but in the 19200 that isn't working you are querying tag #0. As I mentioned in your other post, tag #0 (or 40,001 or 30,001) is NOT supported as it indicates that the channel is not attached to the slave. You must start at tag #1 (or 40,002 or 30,002). You can't even do a block query like you are doing since you are starting at an invalid tag.

Share this post


Link to post
Share on other sites

OK, I have two devices acting as masters reading at different bauds that's why they read different addresses, it was just a coincidence that the one at 9600 started at address 3.

Why DAQfactory can not respond to a command asking register 40001? That's a problem because most of my slave devices start their maps at 40001. Is there a way around this?

Thanks

Share this post


Link to post
Share on other sites

Because 40,001 is actually tag #0 in the modbus frame and 0 means that the channel is to be accessible by the modbus slave device. I'm not sure why its a problem for you. Just start mapping at 40,002. Its just a number.

Share this post


Link to post
Share on other sites

I still don't understand how to do it. The string I receive from the master is:

001-003-000-000-000-032-068-018

And I can not change it. DAQFactory is not responding to this. I tried with Modbus # of 0, 1 and 2. Same result.

Share this post


Link to post
Share on other sites

Modbus RTU translation 101:

1st byte: 001: the modbus ID. This is the default for the DF modbus slave and is correct.

2nd byte: 003: the modbus command. 3 means read holding register. 4 is read input register. DAQFactory accepts both as the same, so either is acceptable for polling values.

3rd and 4th bytes: 000 000: the starting tag # to read. It is big endian, so the first byte is multiplied by 256. 000 000 means tag # 0, 000 001 means tag #1, etc. This corresponds to the Modbus # column of the channel table. As I've said, DAQFactory DOES NOT support 000 000 here as that is used to indicate that the channel is not available from slave.

5th and 6th bytes: 000 032: the number of tags to read. Again, big endian, so in this case, 32.

7th and 8th bytes: 068 018: the CRC. This is a checksum and varies depending on what the rest of the frame has.

As I said, the 3rd and 4th bytes cannot be 000 000. If you master can't output anything else then its simply not going to work.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this