• J
    jvaughters

    Rob987,

    You have run into a common problem that I see all the time. The swapped word issue is defaulted differently by different Modbus master clients. So modpoll can look correct because it assumed (defaulted) the order correctly. As a general rule, if the numbers are not coming out correct swap the words to see if that helps. Other troubleshooting techniques would be to retrieve each individual word and assemble them manually and see if that helps resolve the issue. Furthering the issue, I have found that device documentation can greatly lack in describing the order of their numbers. Of course all of this depends on getting the correct register number resolved first.

    I'm glad you got it resolved.

    posted in Mango Automation general Discussion read more
  • J
    jvaughters

    JF89,

    I have a saying that applies, " It's difficult until you know how"

    I understand there is alot to learn. I promise you it is worth it to put the effort. Mainly because the power of Linux far exceeds the power of Windows, but it does come at a cost. That cost is time digging, trying, and eventually succeeding.

    The alternative if you just want to get up and running is to get a regular Windows computer. Windows IoT is a special beast. You may run into big troubles there. Of course you may not, so feel free to try, but just know Windows IoT could be a challenge as great as learning Linux. Of course I always recommend just trying to see if it works. I think you will find much more support for Linux than you will for Windows IoT and I mean that in a general sense, not just Mango.

    Good Luck in your endeavours!

    posted in Announcements read more
  • J
    jvaughters

    There are multiple embedded computers to choose other than Rpi. Nothing against Rpi, I use them quite a bit, but for Mango I would use a minimum of 2GB memory and then run the board headless with no Xorg GUI. I have chosen a board with 4GB of memory and it was a little over $50 US. However it did take 3-4 weeks to ship. It's the Pine Rock64 with 4GB. I am not using emmc yet, but that would be the next step for me. I only have about 10 points right now, but the custom displays are performing well.

    I also tested on a Solid Run embedded computer with 2GB and headless with no Xorg GUI and it worked well also. In all cases, including Rpi, you will need to restrict the memory for the JVM. Check the forum here at Mango, you will find the way to do it.

    posted in Mango feedback read more
  • J
    jvaughters

    I would add that Java performance on Linux is better than Windows. Oracle generally recommends Linux on most of their products. Specifically they recommend Oracle Linux, which 95% the same to Red Hat. All that to say that I would probably take the time to learn Linux if you want to use Mango. It's actually not that hard.

    Good Luck in your endeavours.

    posted in Announcements read more
  • J
    jvaughters

    However, the refresh work around may be the only way to do it for a device that only allows a single TCP/IP session, so that is a good technique to remember and keep in my tool box. Plus, single point MODBUS requests are not the most efficient, but in reality the load increase is very small in most cases. I like it, thx.

    posted in Mango Automation general Discussion read more
  • J
    jvaughters

    @phildunlap

    Ah! I do get what you are saying about scripting the update. So you could create a timer and use that to run a script to refresh. So your data source could be set to the longest you wanted for a refresh and you could create a script to refresh at shorter intervals. That actually is a nice work around and, oddly it mimics the scan group feature I discussed. It does lead to a question.

    Will the scripted refresh be a single point only, or could you pass it a group of points?
    Would that bypass the Modbus attempt to optimize requests?

    posted in Mango Automation general Discussion read more
  • J
    jvaughters

    @phildunlap

    Correct, my assumption was he unchecked the "Contiguous Batch Only" and it resulted in two requests for 13 and 37 registers per request as opposed to 2 registers per request based on the Modbus logging, which I dearly love that I/O feature. I'm totally lost on the alternative point polling periods you proposed. And that is ok, because I do not need that feature in Mango and will be sure to contact you if I ever do.

    From a general SCADA perspective. Multiple polling rates for different points is handled differently across different systems. Some take over completely and optimize as they see fit and some do that VERY well. Others and my favorite is to create scan groups where you specify the points you want per group and what scan rate you would like for that group. Then the same TCP/IP session can be used by Modbus master to scan the groups as specified. Not sure if Mango would ever consider the scan group idea, but I would certainly like that feature.

    posted in Mango Automation general Discussion read more
  • J
    jvaughters

    • The nnn is ms

    • The only way I know how to have separate point scan times is to create multiple data sources with different scan times. I will let Mango staff have the last word on that. This could be a problem if the inverter does not allow more than one TCP/IP session.

    • That "Contiguous Batch Only" definitely changed the request to ask for larger blocks of data. This may be more friendly to the processor. Meaning less requests to handle.

    Recommendations to try:

    • Try to set the Transport Type to TCP with keep-alive if it is not already. I think that should be the default. I have run into issues where performance is affected if that is not set. The constant TCP session set up and tear down is wasted load time.

    • If the inverter allows more than one TCP/IP session then create a second data source that polls at the 15 min poll rate. If there is another way to do this, maybe the Mango folks will chime in. All settings should be the same for each data source except the points and poll rate.

    • It's highly unusual, but it is possible that the PLC and the inverter have differing TCP stack software. This can lead to devices not talking. I have seen this before in embedded devices that are old. If this is true you could break down the TCP sections from mango and compare them to the PLC TCP packets. It's not likely, but possible. You could also check every bit sent from Mango and compare to every bit sent from the PLC and see how they differ. It can be grueling and may not be worth the time, but if you really want to know this is an option.

    posted in Mango Automation general Discussion read more
  • J
    jvaughters

    Nope, behold was needed, I was just using the log above, it is 1 sec gaps, so that is just a retry and makes sense. I missed the increment. So the question is still why is it needing to retry? Something is holding it up. Network or processor?

    Thx for the beholds too `,~)

    posted in Mango Automation general Discussion read more
  • J
    jvaughters

    So in this case, why did it send out the exact same request in less than a ms? and other times I see it in 1 ms. But why the exact same request in such a short time?

    2019/03/22-21:06:43,356 O 000c00000006010300e20002
    2019/03/22-21:06:44,356 O 000c00000006010300e20002

    posted in Mango Automation general Discussion read more