Mesa 7C81 incorrect GPIO output at startup of LinuxCNC

More
13 Aug 2021 21:34 #217709 by dawidma
Hello,
after several years of using an old Pentium 4 with parallel ports, I now switched over to a combination of a Raspberry Pi 4 and a Mesa 7C81 for my small milling machine.

So far the basics are working (stepper motor control / endstops / keys / e-stop), but I noticed that when I start LinuxCNC, my output signals become unintentional active for 5-6μs.

I designed the electronics in a way that when LinuxCNC is not active that the (by default enabled) pull up resistors cause the outputs to be inactive. The outputs are therefore low-active and inverted in the HAL file.
This works fine when LinuxCNC is not running and when it has finished starting and is driving the outputs via SW, but not during startup.

Even if I tie the output to a constant inactive output, it still gets activated for around 5μs when LinuxCNC starts.
Here are the relevant HAL lines:
setp hm2_7c81.0.gpio.001.is_output 1
setp hm2_7c81.0.gpio.001.invert_output 1
setp hm2_7c81.0.gpio.001.out 0

The order of the above lines seems not to have any impact

Does anyone know how to avoid this short unwanted output activation?

Thank you
Daniel


 

Please Log in or Create an account to join the conversation.

More
13 Aug 2021 22:04 - 13 Aug 2021 22:09 #217712 by PCW
It may be avoidable by changing the low level GPIO parameter update
function in the HM2 driver. It currently updates the DDR before the output
inversion and open drain mode, the DDR update should really go after these.
Do you have LinuxCNC source?

Changing the order of the setp commands is a no-op because they basically
just update software registers that get copied to the hardware by the hm2
driver write function.

A hal fix might be to include the output mode setting in an included hal file
(post_gui maybe). This would delay the output drive enable until the inversion
is done.
Last edit: 13 Aug 2021 22:09 by PCW.

Please Log in or Create an account to join the conversation.

More
14 Aug 2021 14:04 #217751 by dawidma
Thanks for your quick answer, PCW!

Changing the driver would push me too far out of my comfort zone and most probable cause unwanted side effects.

With your reply, I realized that this effect only occurs with inverted outputs. So I tried to use the outputs as not-inverted, which worked fine for a static output signal. Then I tried to invert my logic in the HAL file, but this led to an even longer unwanted output activation (a few ms) after I linked the input of my inverter to the correct input signal (in this case machine-is-enabled).

Since the 7C81 provides much more GPIOs than I will ever need, I now implemented a HW solution/workaround:
I use two inverted outputs to drive both side of the LED of an optocoupler (of course with an current limiting resistor). The output of the optocoupler is used to switch on the supply for the other outputs.
In the HAL file I simply set these outputs to different levels, so that the LED turns on as soon as the HAL file is executed.
During startup of LinuxCNC, these outputs also get unintentionally activated, but since this happens synchronously, my outputs are not supplied in that moment but get switched on shortly after this event.
This solution also disables the output power supply when LinuxCNC is not running (which is not absolutely necessary, but also doesnt hurt).

Please Log in or Create an account to join the conversation.

More
14 Aug 2021 15:50 #217754 by PCW
I think this is an actual bug but the wrong output duration is so short that
it has not been noticed until now.

I suspect most power related hardware doesn't even react to single
5-6 usec pulse

Please Log in or Create an account to join the conversation.

More
14 Aug 2021 20:22 #217768 by dawidma
I agree, typically you wont notice this effect. In my case a soft start circuit was overridden so that the power supply detected a short circuit.

Thanks for your help

Please Log in or Create an account to join the conversation.

More
14 Aug 2021 23:25 #217777 by PCW
I'll push a fix to master. but I don't think it should put be in 2.8
since it affects so many systems and the actual impact is so minor
that it hasn't hasn't been noticed for many years...

Please Log in or Create an account to join the conversation.

Moderators: PCWjmelson
Time to create page: 0.067 seconds
Powered by Kunena Forum