Modbus slave... - it needs to talk...
pacman
Posts: 327
I'm 'thinkering' with an idea. A device that has lots of pre-canned messages on a CF card (perhaps stored as wav files). Then you send serially (rs232/485) a modbus write command to a particular register. Prop then plays appropriate wav file.
So send '17d' to proptalker and then prop reads in file 17.wav and spits its out to a speaker.... or perhaps even says '17Say.wav' and displays '17tv.gif' on the video output...
Does anyone have any "I'm a modbus slave and here is register that you can write to" code they want to share?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
=================
The future is in our hands.
Which way to the future?
=================
So send '17d' to proptalker and then prop reads in file 17.wav and spits its out to a speaker.... or perhaps even says '17Say.wav' and displays '17tv.gif' on the video output...
Does anyone have any "I'm a modbus slave and here is register that you can write to" code they want to share?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
=================
The future is in our hands.
Which way to the future?
=================
Comments
I guess I just got myself another task to go on the "jobs to do over the Christmas break" list - at least this is one I'll enjoy....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
=================
The future is in our hands.
Which way to the future?
=================
Yes the other gear is ModBus. In the majority of applications I'm thinking it would be used in (I have some already in mind in the 'industrial' world I work in) it NEEDS to talk Modbus. And although most of the comms is RTU, I see no real need to stay in RTU. ASCII should be easier (and could probably be sent 'easier' out a standard PLC port).
And yes, I realise it needs to follow the standards, but as I would only be looking at fn06 (IIRC - write single register) then it shouldn't be too hard.... {how's that for famous last words..}
Modbus has so much mindspace that to go any other way (without supporting modbus as a 'default') would make it a very hard sell IMHO.
If it flys then other protocols might be considered in the future (3964R, DMX, WhateverTheCustomerAlreadyHas, etc, etc)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
=================
The future is in our hands.
Which way to the future?
=================
The trick -- though not difficult -- will be mapping all the possible addresses the *could* be in a ModBus device to what you actually want to support. How were you thinking of handling that?
Yep
Two gold stars so far...
Lots of apps on the net to allow you to send modbus to a remote device. PM me if you need help finding them - some are good (and free) and some are rubbish.
No gold star for me
For my application, I only need to other (master) device to be able to send to one of my registers. Lets call it 40001. Provided the remote master device stuffs a number in that register, then I 'play' that numbered message. Once played I would clear register 40001 to zero. I would have a default ID of {say} 7 - probably configurable via jump links (no links = 7, 1 link = 8, 2 links = 9, you get the idea)
The only other extension to this would be to add a single register that can be read by the master device (it issues a fn03) that gives a status back. eg: 0 is not playing message, 9999 = error, any other number is number of message being played. This status idea is not fully 'thinked' out at this stage (so any insight would be appreciated).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
=================
The future is in our hands.
Which way to the future?
=================
If you've got a recommendation of a PC app that I can work with (in Windows) I'd be thrilled.
For the receiving end on the Prop, the Modbus Spec makes the packet format easy to understand. Just be careful with the coil/register offsets having base 1... I think the first coil is at address 0001 instead of 0000, so its easy to miss by one.
I have some receiver code in Basic somewhere if you get stuck, but I think once you look at the Spec you'll be fine
www.win-tech.com/html/modbus1.htm
www.hmisys.com/
The only thing you should implement completely is sending negativ answers (command not implemented, register out of range etc.).
Then the slave-ID should be settable.
Timing-constrains should be observed to detect errors.
The easiest way is to start with ASCII because it is more readable. When that works, switch to RTU. RTU is a requirement, ASCII can be implemented. I can handle both, it's quite easy. Internally, I translate ASCII to RTU. Only difference is timing (detecting the start of a message) and the checksum. Replies are assembled in RTU and translated to ASCII if needed.
You also need to be able to select Baud-rates. And keep in mind, that RS232 is *not* the default!
I've written an almost complete Modbus-slave on the Propeller in Imagecraft's C with an RS232-interface. Then I ran out of HUB-RAM.
Anyhow, it works. Do a search for Modbus here in the forum. Sorry, won't publish code, but willing to answer any question.
I have tried some Modbus-test programs, but then I wrote my own simple one in C. I didn't want to pay ca$h.
HTH,
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
I've implemented an "MODBUS slave" on a propeller powered PLC .
You can send command from a host to the propeller using the standard basic functions :
-03 (Read Holding registers)
-16 (Preset multiple registers)
-32 (derivative usage of func 16 for downloading the ladder program into the PLC)
So you can write or read "registers", but you can make as you want as you have decoded the MODBUS function.
The MODBUS reception is made by a dedicated COG and use fullduplexserial.spin object.
You can easely expand the functions.
I had to extract the MODBUS code from my source and I will post it on the forum, but give me a few time.
Best regards
Dave KI4PSR