@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...
One is for breaking out the RJ45 pins and also connecting them to QWIIC connectors.
There are twin sides that can be connected by a solder switch matrix.
So could be an RJ45 jumper, or could be two separate RJ45 breakouts.
Other one is I/O expander based on TLA2528.
Like this chip because the 8 i/o can be either analog or digital.
The left side is direct connection for digital.
Right side is voltage divider (cause needing to measure 0..10 VDC)
Also, came across something interesting that might help...
Have an I2C IR camera that would be nice to add to system, but needs to be about 1/2 meter away...
Added W6100 module to PLC and also replaced the super long headers with IDC cables.
Seems had to hack the spin2 version of the W6100 code a bit to make it work, but works now.
Think @ke4pjw is going to work in making it better.
Those super long headers were a pain to get connected. If it were just one, maybe wouldn't be as bad, but with two it was very difficult
IDC cables solves this, but now connections are vertically flipped.
Fortunately, this just means changing some constants in the code. The ones that map I/O headers to P2 pins.
Very lucky that both GND and +5V connections each used two pins, tied in vertical direction...
So, vertical flip has no effect...
@Rayman said:
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...
When I first discovered the Prop, my immediate thoughts were: Industrial control.
Had a 10 of these boards made, similar to the one in post #491.
But, don't like it anymore...
Have to redesign...
One idea here was to move the FT231X onto a daughter board, in case didn't need or wanted something else to connect to the USB port.
But now, thinking that was a bad idea and will put the FT231X back on board.
Also, looks like IDC cables to bottom board works, so will replace the middle two 12-pin connectors with regular ones instead of these smt ones.
Think everything else is OK.
The header for Wiznet daughter board has been tested and works...
Actually, need to expand that square hole in the middle just a bit so that the 3d printed jig can pop out the SWaP module.
Using the PLCC extractor tool works, but have also damaged some things on the SWaP if not very careful.
So, now wanting to always push it out from the bottom...
Got one issue to sort out... Seems these OMROM signal relays are taking out the I2C momentarily...
Code can recover by processing the ACK signals, but not happy.
Not sure what is going on, but AI suggests there's an inductive spike when the coil turns off.
Think that must be it...
Having the ability for the software to recover gracefully is good. And also good to maintain an event counter of these errors too. You definitely want to know when this is repetitive since electrical damage is possible. And you never know, it might be helpful for your own sanity ... I recently improved my comport settings by monitoring the rate of modbus errors.
There's two possible electrical problems to cover. First is the coil flyback and solenoid spring return pulse back onto the coil drive component - presumably a prop pin. Second is potential RF arcing across the contacts of the relay. The effect on surrounding electronics from arcing is relative to both proximity and intensity of the arc.
There's multiple ways to improve the electrical side of things. A schematic is very helpful at this point.
The input is very simple... Just some OMRON G6K signal relays with 24V coils. When the coil is activated, a P2 pin is pulled down to ground, these have internal 15k pullups activated.
The other strange things is that there are 8 inputs to this relay array, but only the ones connected to switches right on the enclosure are giving me this trouble.
Do think it is the turning off of the switch where the I2C glitch happens, but need to verify that.
The current is very tiny here, think 2 mA, so very surprised this is happening...
But, maybe this mechanical switch has a lot of bounce and causing flyback EMI.
It is good that the I2C code can detect errors and ignore suspect input, but still not happy.
@Rayman said:
That’s an option .. have to see if there are 24 v versions
Just add a resistor. Have a look at PLC manuals. They often document their I/O circuits so there is no confusion when wiring them up.
EDIT: Here's one I Googled. It has two commons so one common can be wired NPN and other PNP. You could instead have separate terminal pairs for each input.
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...
Designed up two new board to help the cause...
One is for breaking out the RJ45 pins and also connecting them to QWIIC connectors.
There are twin sides that can be connected by a solder switch matrix.
So could be an RJ45 jumper, or could be two separate RJ45 breakouts.
Other one is I/O expander based on TLA2528.
Like this chip because the 8 i/o can be either analog or digital.
The left side is direct connection for digital.
Right side is voltage divider (cause needing to measure 0..10 VDC)
Also, came across something interesting that might help...
Have an I2C IR camera that would be nice to add to system, but needs to be about 1/2 meter away...
This Sparkfun QWIIC BUS thing looks like just what is needed.
Lets you use RJ45 cables to connect QWIIC things over distance in a more noise immune way:
https://www.sparkfun.com/sparkfun-qwiicbus-endpoint.html
Added W6100 module to PLC and also replaced the super long headers with IDC cables.
Seems had to hack the spin2 version of the W6100 code a bit to make it work, but works now.
Think @ke4pjw is going to work in making it better.
Those super long headers were a pain to get connected. If it were just one, maybe wouldn't be as bad, but with two it was very difficult
IDC cables solves this, but now connections are vertically flipped.
Fortunately, this just means changing some constants in the code. The ones that map I/O headers to P2 pins.
Very lucky that both GND and +5V connections each used two pins, tied in vertical direction...
So, vertical flip has no effect...
Now that it has ethernet, can start working on Modbus TCP...
When I first discovered the Prop, my immediate thoughts were: Industrial control.
@ChrisGadd has also provided a CAN FD driver
Had a 10 of these boards made, similar to the one in post #491.
But, don't like it anymore...
Have to redesign...
One idea here was to move the FT231X onto a daughter board, in case didn't need or wanted something else to connect to the USB port.
But now, thinking that was a bad idea and will put the FT231X back on board.
Also, looks like IDC cables to bottom board works, so will replace the middle two 12-pin connectors with regular ones instead of these smt ones.
Think everything else is OK.
The header for Wiznet daughter board has been tested and works...
Actually, need to expand that square hole in the middle just a bit so that the 3d printed jig can pop out the SWaP module.
Using the PLCC extractor tool works, but have also damaged some things on the SWaP if not very careful.
So, now wanting to always push it out from the bottom...
Got one issue to sort out... Seems these OMROM signal relays are taking out the I2C momentarily...
Code can recover by processing the ACK signals, but not happy.
Not sure what is going on, but AI suggests there's an inductive spike when the coil turns off.
Think that must be it...
Having the ability for the software to recover gracefully is good. And also good to maintain an event counter of these errors too. You definitely want to know when this is repetitive since electrical damage is possible. And you never know, it might be helpful for your own sanity ... I recently improved my comport settings by monitoring the rate of modbus errors.
There's two possible electrical problems to cover. First is the coil flyback and solenoid spring return pulse back onto the coil drive component - presumably a prop pin. Second is potential RF arcing across the contacts of the relay. The effect on surrounding electronics from arcing is relative to both proximity and intensity of the arc.
There's multiple ways to improve the electrical side of things. A schematic is very helpful at this point.
The input is very simple... Just some OMRON G6K signal relays with 24V coils. When the coil is activated, a P2 pin is pulled down to ground, these have internal 15k pullups activated.
The other strange things is that there are 8 inputs to this relay array, but only the ones connected to switches right on the enclosure are giving me this trouble.
Do think it is the turning off of the switch where the I2C glitch happens, but need to verify that.
The current is very tiny here, think 2 mA, so very surprised this is happening...
But, maybe this mechanical switch has a lot of bounce and causing flyback EMI.
It is good that the I2C code can detect errors and ignore suspect input, but still not happy.
What have you done? Relays are normally outputs only. Use optocouplers for inputs.
That’s an option .. have to see if there are 24 v versions
Just add a resistor. Have a look at PLC manuals. They often document their I/O circuits so there is no confusion when wiring them up.
EDIT: Here's one I Googled. It has two commons so one common can be wired NPN and other PNP. You could instead have separate terminal pairs for each input.
Ok, think will switch the inputs to optoisolators... Will keep relays for outputs though.
Have used this kind in the past, think fine for this too:
https://www.digikey.com/en/products/detail/onsemi/H11L1SM/400369
Bit torn between SMD and through hole, but thinking SMD is better since also need a resistor for it.
Looks like a 10k resistor would be perfect for 24V signals.
Actually SMD is too big, switching to through hole...
I'd recommend this as it handles both wiring conventions - https://www.digikey.com/en/products/detail/toshiba-semiconductor-and-storage/TLP2391-TPL-E/7809655
BTW: If you don't need the fast logic output you'd get notably lower power consumption by changing to open-collector outputs for the bulk of the optocouplers. They're third the price and use less pins - https://www.digikey.com/en/products/filter/optocouplers-optoisolators/transistor-photovoltaic-output-optoisolators/903?s=N4IgjCBcoCwdIDGUBmBDANgZwKYBoQB7KAbRDgFYA2ATgpAF0CAHAFyhAGVWAnASwB2AcxABfAjADsMKKGSR02fEVIgAzAAZJagEwQmINh279hYggFodspFF4BXZcUhl6DUeJD0EzKGBa+kDoUnlQ2fAAmHBZgGhAs7JAgIASsAJ7MOBxoWMgeQA
The four-pin one would improve my layout... Will take a look at that...