Connection to EDMI energy meter


ntsomerville

Recommended Posts

I am successfully communicating with EDMI Atlas series Energy meter on Chn # 9001.  (MODBUS RTU)

I cannot find an I/O type to suit the data response and therefore don't get any in the value Column for my channel that I have set up .  The device manual states that the data is 'Swapped Float'

I have manually decoded the response in the Comm Monitor and I get the correct float value. (244.99985). I believe it is a 'Float - Mid-Little Endian (CDAB)'

image.thumb.png.dbfad6c8ea713c6bab262ac2a1f35115.png

Link to comment
Share on other sites

Yes, it looks like they swapped the bytes in each word.  That is a very unusual form.  DAQFactory has three forms it will read directly.  "Float", "Float R Bytes" and "Float R Words".  I would try Float R Bytes.  If that doesn't work, you will likely need to read the value in as two different U16 words in two channels and then reorder things.  Use the From. and To. functions to do this, though really, probably just To.Float().  So, if you had two channels, called, simply First and Second, where First would end up having 0xffff in your case, and Second would have 0x4375, the final float value would be something like:

to.Float(concat(transpose(from.Word(First),0), transpose(from.Word(Second),0)))

You might need From.RWord() instead of From.Word(), and / or swap first and second.

 

 

Link to comment
Share on other sites

Thanks for your prompt reply.  I have had no luck with the 'Float R Bytes'.  I have also tried all the 'Read Holding Uxx (3)' options and still don't get any data populating my channel.  The Comm Monitor shows the valid MODBUS responses for all the options I tried.

This is what I get using I/O Type: Read Holding U16 (3), with no channel data available.

Tx (15:40:56.001): \x01\x03\x23\x29\x00\x01\x5E\x46
Rx (15:40:56.016): \x01\x03\x02\x43\x70\x88\x90
Tx (15:40:58.000): \x01\x03\x23\x29\x00\x01\x5E\x46
Rx (15:40:58.015): \x01\x03\x02\x43\x70\x88\x90
Tx (15:41:00.000): \x01\x03\x23\x29\x00\x01\x5E\x46
Rx (15:41:00.015): \x01\x03\x02\x43\x71\x49\x50
Tx (15:41:02.000): \x01\x03\x23\x29\x00\x01\x5E\x46
Rx (15:41:02.015): \x01\x03\x02\x43\x71\x49\x50

 

This is the only MODBUS device that DAQFactory has had trouble with.   Oddly enough, I can talk to it with a python script, using the minimalmodbus library, and it works fine. 

 

Link to comment
Share on other sites

You should get data into the channel for Read Holding U16.  You are getting 0x4371 or 17265 decimal.  But this probably isn't what you want.  Are any of the registers actually 16 bit words?

It is important to understand that byte ordering is largely based on the processor, and sometimes the programming language.  Modbus itself specifies big endian and only defines 16 bit words, meaning the high order byte is first, then the low order byte.  Floating point and 32 bit integer values in Modbus are totally made up by the hardware and do not exist in any Modbus spec.  In pretty much every case I have ever seen in 25 years up till this one, the byte ordering within each word remains big endian, but the ordering of the two registers (the two 16 bit words) will vary between big endian and little endian.  That is why we have Float and Float R Words.  There is also R Bytes, but I have never seen that used because Modbus explicitly species the byte ordering as big endian in the spec even though it doesn't specify anything about 32 bit values. 

Your case seems to be R bytes and R words, which, as I said, I have never seen.  DAQFactory doesn't have an I/O type for this because it has never come up in 20 years.  How many of these values do you need to read?  That will determine the best course of action. If it is only a few, on a single device, then the script workaround I gave you before will do the job.  If it is a lot of tags, then we can talk about a different solution.

Link to comment
Share on other sites

Thanks so much for all the excellent information.

I am still at a loss to what was going on.  I was not getting any data into my channel despite the above Comms Monitor output. This was on a brand new DAQFactory document, with only the one channel and device.  In frustration, this morning I removed the channel and re-instated it and everything worked fine!!  (Something I probably should have done much earlier!)  The Comms monitor output was identical to the above post.

Now is the time I have to admit that I am losing my mind.  I was actually 1 out with the register for my original post, so the data is actually Float - Big Endian (ABCD), so I am getting exactly what I want using Read Holding Float (3).  So there is nothing strange about the MODBUS that this manufacturer is using! 

Why I was getting nil output from my original channel is still a mystery.

At least all is good now.

Sorry to be a trouble maker!

 

 

Link to comment
Share on other sites

Glad you got it working.  If no data is coming in, then it is a different issue than formatting.  Improper formatting won't really affect the data coming in unless the device rejects it.

Your story, though, reminds me of a joke I just heard:

Four people get into a car and the car doesn't start.  The engineer says, "Oh, it must be the starter".  The electrician says, "Oh, it must be the battery".  The chemist says "Oh, it must be something with the fuel".  The IT guy says "Hey guys, let's get out of the car and then get back in and I'll bet it will start working!"

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.