Hi Chris,
Thanks for info. I will try to un-brick my units tomorrow.
100ms pulse is not main problem (of course it will allow us to invert the logic). But main problem is n_reset line.
You have seen screenshot from oscilloscope. n_reset line on FX30 are in high state on boot and everything on IoT card works without any control on boot.
I checked n_reset on mangOH green - n_reset line is not active on boot. It prevents from unintentional behaviour. I activate n_rest after boot and gain control on IoT card.
I checked n_reset on mangOH red - n_reset line is not active on boot. Again, it prevents from unintentional behaviour. I activate n_rest after boot and gain control on IoT card. I do not have screenshot from oscilloscope, but I have taken photo when mangOH red was on boot. As you can see green LED is on - GPIO is active, but I have got 0V on my multimeter. When I activate n_reset line, multimeter shows 1.8V. It is save solution.
I wanted to inform you, if someone used FX30 to control machine right now, it would be against EU law.
Please read Machinery Directive EU (Points 1.2 Control machine)
“Control devices must be designed or protected so that the desired effect, where a risk is involved, cannot occur without an intentional operation” - FX30 cannot cover it.
Please do not try to convince me that everything is fine with n_rest line on FX30, because is not.
It is second massive difference between managOH units and FX30:
- RTS/CTS line is on IoT cards, on mangOH green and red. FX30 does not have RTS/CTS line on IoT. We could not relay on RTS/CTS when we were designing new IoT because it would work on mangOH units not on FX30.
- n_reset works correctly on mangOH units, but incorrectly on FX30.
Please consult internally issue with n_reset line. 100ms pulse is nothing compering n_reset problem. And please pay attention to differences between FX30 and mangOH units
Best regards
Bartek