Adding UNICAST device to HAH livebox

10 replies [Last post]
vores8
Offline
Joined: 1 Mar 2012

My house lighting is controlled by a PLC that is not a xAP device at all. I've managed to write a custom xAP stack for it (in CodeSys ST language), but still - it was not accepting broadcast messages like 192.168.1.255. To solve this I created a simple lua applet that intercepts broadcast messages to the specific target (khome.PLC.41) and sends UDP datagram directly to PLC IP (192.168.1.50)

 

AttachmentSize
plchelperApplet.lua738 bytes
brett
Offline
Providence, United States
Joined: 9 Jan 2010
BSC to the rescue

What you might want to do then is use LUA to create a BSC endpoint that is synthetic for this PLC and that will act as a bridge for its native control protocol.   Then you can treat it like an xAP device and not have to worry about the unicast/broadcast issues, it will also then integrate nicely with the whole xAP stack.

Nice job on the socket capture and redirect thuo.

This would be even cooler.

Brett

vores8
Offline
Joined: 1 Mar 2012
lua modbus

Hmmm... This is really interesting idea. PLC uses Modbus protocol (like most of the PLC's i believe), so it would require lua modbus master implementation. That's not a disaster but raises 2 questions

1) will livebox survive being a modbus master? i mean processor resources, memory etc

2) if answer to (1) is not "definitely yes", maybe it's more feasible to implement modbus master as livebox native service?

But I will try to come up with some lua modbus implementation anyway

brett
Offline
Providence, United States
Joined: 9 Jan 2010
I found this

I found this http://www.opendax.org/ which also has a set of LUA binding for the C backend modules once of which is MODBUS.   Might be worth looking into.

Anyway let me know how you get one this might be worth rolling into the code base.

Brett

brett
Offline
Providence, United States
Joined: 9 Jan 2010
You know what I think?  A set

You know what I think?  A set of LUA wrappers around http://libmodbus.org would be the way to go, this is by far the most stable and best modbus library out there.   Writing a high level set of LUA API's onto this would give power and simplicity with code that is already proven to be stable and reliable.

Which brings me to this http://think-deep.com/wiki/freesigs/start looks like he has the same idea and has already done all the API wrappings - this would do nicely.

Although what he does is use LUA as an internal scripting language to a C driver which runs as a daemon.  We should be able to work with that as all the xAP code for us is written in pure LUA - it should just work(tm).

What do you thing?

derek
Offline
Glasgow, United Kingdom
Joined: 26 Oct 2009
The bigtime ...

I've always liked MODBUS. It reminds me of the good old days when I programmed avionic units using 1553B. No doubt that adding this sort of thing to the HAH would up our game.

The Lua wrappers from Freesignals look neat.

Of course, the main problem is the cost of establishing a decent test framework for MODBUS. e.g. check http://www.ebay.co.uk/itm/WAGO-750-841-ETHERNET-TCP-IP-PROG-FIELDBUS-/251002788148?pt=UK_BOI_Industrial_Automation_Control_ET&hash=item3a70ee9934#ht_500wt_950

This gives us 10 inputs and ten outputs for £3196 (£159 per I/O). Compare with a HAH and our PPE expander giving 32 I/Os for under £75 (£2.34 per I/O)!

Derek

p.s. OK, I concede that the WAGO unit has nicer connectors

vores8
Offline
Joined: 1 Mar 2012
keep it simple?

My impression that using libmodbus/freesigs is a bit heavy-weight. My current setup is

PLC that has all the lighting control logic (I am pretty comfortable with ST programming)

A number of modules that are connected to PLC via RS485 by Modbus RTU

PLC logic is self-contained, it processes all the button presses, including long clicks, double clicks, scene management etc. Functionaly the logic consists of 2 types of objects: scene (which processes inputs from buttons) and light (which is simply a boolean state). A single scene can affect multiple lights. From a xAP standpoint scene is a output and light is an input. So the only thing that I can do with a scene is to switch it on/off: switching off obviously switches off all the lights attached to the scene, switching on the scene lights up the lamps in the scene that were lit last time the scene was switched off.

Using freesig will allow me to move this logic to the HUH, but I suspect this will not give me any major benefits. First, PLC logic heavily depends on button press timings and adding additional communication step will introduce some delays that can make logic unpredictable.

So, for the modbus-xap bridge I am going to have the following

expose PLC scenes and lights as modbus TCP slave variables (1 bit for each)

on HAH side have all PLC scenes mapped to BSC endpoints as bsc.output and lights as bsc.input

on HAH side have a timer that will interrogate PLC once or twice per second to get the states of the scenes and lights. This can be done by a simple socket send/receive call.

if scene or light state is changed then bsc.event message is fired.

Another timer on HAH gets data from PLC slave every 60 seconds to produce bsc.info messages

If HAH script gets a bsc.cmd targeted to a bsc-mapped scene, it sends modbus command to update scene bit accordingly. PLC will take care of that and as a result update it's DIs and slave registers (which will result in bsc.event command as described above)

All of the above can be done by simple lua socket send/receive calls and can result in a really simple script

I will post it here as soon as it's ready

brett
Offline
Providence, United States
Joined: 9 Jan 2010
Perhaps I am over simplifying

Perhaps I am over simplifying a little but I would think a framework something like this would suffice.  I'm not sure why you are polling for the INFO message.   The BSC framework takes care of all this nitty gritty for you.  Or maybe you didn't notice this.

This i really rough and there are a few things I've not considered but to keep it simple, I've made sweeping assumptions.  The devil is in the detail.... :)

Brett

AttachmentSize
modbusApplet.lua 1.31 KB
vores8
Offline
Joined: 1 Mar 2012
eppur si muove :)

My version attached. This script simply sets single coil (modbus function 05). At the PLC side appropriate register is being checked every cycle and when it goes to 1, PLC does the job and sets this register to 0. Works flawlessly for more than a month for now

Thanks guys for a great software

AttachmentSize
modbusgateApplet.lua 4.54 KB
brett
Offline
Providence, United States
Joined: 9 Jan 2010
vores8 that is nicely done,

vores8 that is nicely done, so much control, so little code.  Love it.  I'll take those thanks  :)

vores8
Offline
Joined: 1 Mar 2012
Enjoy :)

Please note that every xap endpoint uses two single-bit coils of the PLC - one for "control" as explained above, and one for "state". This is due to plc has it's own internal logic and inputs (switches attached, timers etc), so the state of each scene (plc scene is mapped to xap endpoint) is controlled internally by plc using the "state" coil to inform hah on changes emitting appropriate events

Hardware Info