@Rayman said:
@Mickster Modbus complicated? Seems super simple to me, at least after a bit of study. I'm not really sure it could get any simpler...
But, I'm only implementing a small subset of the commands. Thinking that only 4 or 5 are really needed. Modbus scanners mostly only use the first four commands. That's probably enough for most use cases.
If you plan to support Modbus then you can't expect to be successful with a small subset. One of many issues:
Modbus does not define how 32- or 64-bit data types are sent; it only defines the sending of 16-bit words and bits.
Since there is no standard, to send a 32-bit data type, some manufacturers send the most significant 16-bit word first, and others the other way around.
If you plan to support Modbus then you can't expect to be successful with a small subset.
Why? A MODBUS slave can return an exception response message that tells the master the requested function isn't available in the device, or that there was a problem with a parameter in the command message.
In my experiments the MODBUS apps have displayed an appropriate error dialog when getting an exception response.
con
#01, EC_FUNC, EC_ADDR, EC_VALUE, EC_FAIL
pub exception_response(code) | crc
if (rxbuf[0] == BROADCAST)
return
txbuf[0] := myaddr ' create response
txbuf[1] := rxbuf[1] | $80 ' convert to exception
txbuf[2] := code ' code for details
crc := calc_crc(@txbuf, 3)
bytemove(@txbuf[3], @crc, 2) ' add crc (Little Endian)
send_msg(5) ' reply to master
if (DISPLAY_REPLY == YES)
term.str(@" Error ") ' show response on terminal
show_msg(@txbuf, 5)
term.tx(13)
@Mickster said:
It's retarded
Pofibus is retarded
CAN-bus and EtherCAT, don't get me started.
DeviceNET, totally retarded.
I'm from the year 2025 and we don't tolerate this shite anymore.
This mentality is perfectly described in The Emperor's New Clothes.
So what is the solution you are proposing? Anything new that is incompatible with the existing solutions must be truly compelling in order to overcome inertia.
@Mickster said:
It's retarded
Pofibus is retarded
CAN-bus and EtherCAT, don't get me started.
DeviceNET, totally retarded.
I'm from the year 2025 and we don't tolerate this shite anymore.
This mentality is perfectly described in The Emperor's New Clothes.
Well, the problem is always the same. You want to design a new system. You have to make the decision if you a) develop everything from scratch or b) you try to use existing standards or at least build upon something that's already there.
If your company has a big name and you plan to make a "Jack of all trades" then you have to come up with something like EtherCAT that is extremely compex to fit all purposes. Many people have to be in the boat and the documentation will be a nightmare, it's going to be expensive and so on...
But if you only need to fill a small niche you can use a subset of an existing standard. So it's limited but simple and efficient. If the standard doesn't fit your purpose perfectly you can enhance or modify it. But it's still better than to come up with something completely new. This way you can use existing tools and don't have to re-invent the wheel.
The best part for me is that even though the code isn't all written, can already tell the Siemens PLC people exactly what data there is going to be and exactly how to get it using a way that they understand.
For the PLC type project I'm working on, really liking having 8 cogs for things.
Read that keeping the cycle timing constant can be a challenge.
But, with P2, the main cycle for me is in its own cog and there's nothing that can break the timing.
This main cog looks at input bits "relays" and then adjusts output bits "coils" accordingly.
These are all digital inputs to the P2 (buffered by actual relays) or via I2C expander.
So there's nothing there to through it off the rails (although, now that think about it, should double check the I2C part to make sure this is true...).
The things that could be problematic like serial and TCP communications are all put in their own cogs.
Don't personally have much experience with other microcontrollers, but can see doing everything that this thing is doing would be a challenge.
Maybe you could do it with a bunch of interrupt handlers, but it wouldn't be fun and maybe not as reliable...
Comments
If you plan to support Modbus then you can't expect to be successful with a small subset. One of many issues:
Modbus does not define how 32- or 64-bit data types are sent; it only defines the sending of 16-bit words and bits.
Since there is no standard, to send a 32-bit data type, some manufacturers send the most significant 16-bit word first, and others the other way around.
Nightmare incoming.
Why? A MODBUS slave can return an exception response message that tells the master the requested function isn't available in the device, or that there was a problem with a parameter in the command message.
In my experiments the MODBUS apps have displayed an appropriate error dialog when getting an exception response.
con #01, EC_FUNC, EC_ADDR, EC_VALUE, EC_FAIL pub exception_response(code) | crc if (rxbuf[0] == BROADCAST) return txbuf[0] := myaddr ' create response txbuf[1] := rxbuf[1] | $80 ' convert to exception txbuf[2] := code ' code for details crc := calc_crc(@txbuf, 3) bytemove(@txbuf[3], @crc, 2) ' add crc (Little Endian) send_msg(5) ' reply to master if (DISPLAY_REPLY == YES) term.str(@" Error ") ' show response on terminal show_msg(@txbuf, 5) term.tx(13)So what is the solution you are proposing? Anything new that is incompatible with the existing solutions must be truly compelling in order to overcome inertia.
Well, the problem is always the same. You want to design a new system. You have to make the decision if you a) develop everything from scratch or b) you try to use existing standards or at least build upon something that's already there.
If your company has a big name and you plan to make a "Jack of all trades" then you have to come up with something like EtherCAT that is extremely compex to fit all purposes. Many people have to be in the boat and the documentation will be a nightmare, it's going to be expensive and so on...
But if you only need to fill a small niche you can use a subset of an existing standard. So it's limited but simple and efficient. If the standard doesn't fit your purpose perfectly you can enhance or modify it. But it's still better than to come up with something completely new. This way you can use existing tools and don't have to re-invent the wheel.
The best part for me is that even though the code isn't all written, can already tell the Siemens PLC people exactly what data there is going to be and exactly how to get it using a way that they understand.
For the PLC type project I'm working on, really liking having 8 cogs for things.
Read that keeping the cycle timing constant can be a challenge.
But, with P2, the main cycle for me is in its own cog and there's nothing that can break the timing.
This main cog looks at input bits "relays" and then adjusts output bits "coils" accordingly.
These are all digital inputs to the P2 (buffered by actual relays) or via I2C expander.
So there's nothing there to through it off the rails (although, now that think about it, should double check the I2C part to make sure this is true...).
The things that could be problematic like serial and TCP communications are all put in their own cogs.
Don't personally have much experience with other microcontrollers, but can see doing everything that this thing is doing would be a challenge.
Maybe you could do it with a bunch of interrupt handlers, but it wouldn't be fun and maybe not as reliable...