« RELEASED: emc 2.2.8 | Newest entries | mouse wheel mpg »
I've been toying with a lot of things recently. Ladder Logic for PIC and AVR (GPL), compiled it with wine-dev and tried to port it to the atmega168 on Arduino boards, but unfortunately I've still got a bug--probably in the setup of timing-related registers. There's not a direct connection to emc here, but I know there are a lot of ladder logic fans out there to whom this might be appealing. freemodbus, a BSD-licensed modbus slave implementation for embedded systems. I did succeed in running that on my Arduino, and got it to communicate with both a standalone modbus master and with emc2's classicladder in TRUNK. I still maintain that making the modbus hardware interface an inseparable part of classicladder is the wrong thing to do, but as long as it's the only generic modbus interface someone's contributed, well, it's better than nothing.
In doing that, I found bugs in freemodbus--its "report slave id" function seems to be broken, not writing a byte count where it should--and in the modbus master library used by emc2 TRUNK's gs2_vfd and in my standalone exercise program--its "report slave id" function is also broken, by hardcoding a probably-incorrect response length. So was its read input registers request, for a similar reason.
Of course, my litany of modbus-related complaints wouldn't be complete without a complaint about the Specification and Implementation Guide for MODBUS over serial line in which they explain on page 13 the inter-byte timing requirements of MODBUS RTU, then immediately say in a "remark" that in fact you should do something almost entirely different.
Having modified both the client and the server of the modbus protocol before
they would talk to each other, I'm forced to ask: do either of them talk modbus
at all? Good question!