12-12-2021 05:03 PM
Good day,
seems in modbus you can broadcast to address 0 to send something to all slaves. But when I try that I get error
SubVIs.lvlib:RTU Data Unit.lvclass:Read ADU Packet.vi:5030001
In broadcast mode modbus slaves don't reply, so this will cause that error?
Thanks,
Steffen
12-13-2021 03:17 AM - edited 12-13-2021 03:20 AM
Obviously on a broadcast the devices can't all answer at the same time so it makes sense that they do not answer at all with any message.
I have however never come across an application that would have needed Modbus broadcasts so I think it is a bit of an esoteric feature. I also can't really remember having read about this possibility in the official Modbus documentation. But that document is anyhow VERY brief on the server address use, so it may not be authoritative on that matter. But it could as well be a custom extension of the protocol by some manufacturer. Another manufacturer may allow for a valid server address of 0 too. My guess is that there is some device that used broadcast on Modbus TCP using a network broadcast address and some zealous engineer somehow wanted to port that to Modbus Serial in some way.
In light of this I doubt it would be a good idea to have NI change the Modbus library to anything else as it is now, unless you can point out a document on modbus.org that states that broadcast to address 0 is an officially specified feature.
You still can create your own copy of the Modbus library where you disable the execution of the Read ADU Packet.vi function when sending a command to the server address (Unit ID) 0.
12-13-2021 03:43 AM - edited 12-13-2021 03:45 AM
I deleted the error that results from the slave(s) not responding, so the program runs all the way through, so far so good.
This is used by our EBM fans, for adressing them. Say you don't know the slave address, then you just send a known value into the register that holds the slave address. If its just one slave, then you got its address set. Or say you got 20 fans, then you broadcast the speed to all of them in one sweep.
Trouble is, its the except same command that I am sending now as in the users manual, still not working. But that's not a Labview issue...
12-13-2021 04:19 AM - edited 12-13-2021 04:22 AM
Just deleting the error is a quick and dirty fix that only works for testing. Each attempt to read data that is not available results in a timeout on the VISA Read node. So everytime you send out data like that to address 0, your VI is delaying execution for the duration of the timeout that is set for the session. That will really slow down your communication loop a lot if you do that more than once.
Instead, if your device is meant to not send anything when addressed with server address 0, you should modify your function to not expect anything to be sent too.
It definitely sounds like the EBM engineers modified the Modbus specification with some features of their own. Something engineers tend to like to do all the time. Take a standard and make it just that tiny little bit better, but of course it means it is then not standard compliant anymore.
12-13-2021 01:47 PM
its just for trying things quickly, before I implement it in other software. Seems to be a standard command though.
Suppose just have to keep trying, maybe with some modbus software. For a known address my program works, I manage to change the slave address. But in broadcast mode it does not work. Another, bad, solution would be to make a loop, address all from 1 to 255, but thats not really helpful.
Broadcast is write only.
https://modbus.org/docs/Modbus_over_serial_line_V1.pdf
In broadcast mode, the master can send a request to all slaves.
No response is returned to broadcast requests sent by the master. The broadcast requests are necessarily writing commands. All
devices must accept the broadcast for writing function. The address 0 is reserved to identify a broadcast exchange.
12-13-2021 03:08 PM
And what prevents you to modify the VI library accordingly for this? You can file a bug report with NI, it will be added to the bug report database but it is a big question when they will review this library and possibly make a change. You can wait for that of course but by the time this happens your project is long finished already.
12-13-2021 03:45 PM - edited 12-13-2021 03:48 PM
The whole thing is meant to be a PLC program. I made some small vi's just for testing each step, because to me its easier than doing this in the PLC program. So I made some modbus sender, some modbus receiver and also connected a modbus sniffer. That all can be done much easier on a laptop than fiddling around with the PLC. PLC program is Italian, some things are translated very loosely....
And in the modbus sniffer it turned out whatever my vi sends is the same thing as what EBM's software is sending, so the problem is elsewhere. Now, EBM's helpline is even more useless than a hole in the head...