Please Note This forum exists for community support for the Mango product family and the Radix IoT Platform. Although Radix IoT employees participate in this forum from time to time, there is no guarantee of a response to anything posted here, nor can Radix IoT, LLC guarantee the accuracy of any information expressed or conveyed. Specific project questions from customers with active support contracts are asked to send requests to support@radixiot.com.
New to Mango - Modbus Retention Issue/Question
-
Hello All,
Nice forum you have here! I will preface this by saying I did try the search feature, but didn't find any help with what I need.
OK, so I am new to Mango and am trying to create a basic HMI for some of the MODBUS-enabled devices that my company sells. The issue I am having is the retention of Modbus values when writing to a control word using Mango.
Application Information:
IP Address: 192.168.0.100
Device ID: 192
Offset (0-based): 29921
Type: Holding Register
Data Type: 2 byte, unsignedIssue:
The register in question (29921) is used to turn a motor on and off. Bit 0 of the word is 'Right rotation', bit 1 is 'Stop' and bit 2 is 'Left rotation'. A high bit in either bit 0 or 2 will rotate the motor as noted. A high bit in 1, regardless of bit 0 or bit 2, stops the motor. Commands to reverse the motor without first stopping the motor are ignored by the Modbus end-device.Whenever I use the Datapoints utility screen and 'set' the desired value (1.0 or 4.0), either the motor turns on for a split second and shuts back off or it doesn't turn on at all, with the end result always showing the returned value of '2.0' (bit 1, the stop bit, as high).
If you're still with me, I am convinced this is a function code issue of some sort, possibly a watchdog timer issue. I know the Modbus device works as expected when using Modscan32 simulation software. More interestingly, if I run Modscan32 concurrently with Mango, I can set the desired value from Mango's Datapoints utility screen and the value seems to 'stick' or retain as I would expect it to. The motor will turn on and stay on indefinitely so long as Modscan32 is polling in the background. As soon as I disconnect Modscan32, the register jumps back to '2.0' and the motor subsequently shuts down. All of this said, the only thing Modscan32 was doing in my test setup was polling the same register and displaying the value on screen - I didn't use it to force/write any values.
I am asking for help IDing my problem, because, quite frankly, I am stuck. I played with all of the settings I could think of and still have no luck getting it to 'stick'. I changed the data type to binary and added three datapoints to try controlling each bit on it's own - same result. I also tried messing with the timeouts, refresh intervals, the 'write-type' of the register (both write-only and settable) and countless combinations thereof...
Any help with this would be greatly appreciated! Thanks!
-
Hi and thanks for posting. I think what is happening is that Mango is too smart for what you are trying to do in that it will attempt to use the most efficient function code and when trying to control individual bits it doesn't work out as expected. I'm pretty sure if you create a binary datapoint for each bit it will work as needed. See the attached screen shot for the settings to try and let me know if that works. If not I can think about another way around this.
Thanks,
Joel.Attachment: download link
-
Hello Joel,
Thanks for the quick response! I tested that earlier and had similar results, but I decided to test it again just in case. Unfortunately, I am still getting the same result this time around as well. Please see the sequence of screenshots that illustrate what occurs and the screenshot showing the configuration of the 'MotorControlStop' bit. Thanks for your assistance!
Attachment: download link
-
This is really odd. I'll set up a quick test on my system tomorrow and see what I find.
Thanks,
Joel. -
Thanks Joel. The more I think about this, I am feeling more certain it is a function code issue..
-
I tested this with a PLC I have and it worked as expected. Just to make sure we are doing the same thing I make a screen video (no sound). There is an option on the Modbus data source setting to log the IO. This will log the raw traffic to a file. I'm attaching mine here for comparison but if you want to send me that I might be able to see what's different with your system.
Attachment: download link
-
I appreciate your efforts, Joel. I used WireShark to examine the Modbus request Mango issued versus what the request looks like when issued from Modscan32 and I cannot, at least outwardly, spot a difference between the two. I retract my earlier suspicion of a function code issue, as both programs are using the same function code and identical structuring for the request. I suspect it is something higher level - what, though, I cannot be sure of.
I think the most interesting thing to me is that if Modscan is run concurrently with Mango, I can use Mango to force the registers and they hold. As soon as I disconnect Modscan polling, the register in question auto-populates as 2 (stop bit enabled). I see the same behavior even before I launch Modscan - it's like the end device is rejecting the Modbus command if it originates from Mango and puts itself in a safe mode.
Either way, I would like to revisit my setup with a different Modbus product and see if I get similar results. I am using a USB LAN interface, so that could part of the issue, too. Please don't worry about supporting this application further until I can test to see if it's product issue on my end or something to that effect. Thanks!
-
No problem at all. I wonder if it has to do with the polling rate? Maybe the device needs to be polled at a certain rate and the other software you are using is polling faster than you have Mango set at. You can try setting Mango to a faster rate and see if that helps.
