Default state of output pins

[OJthe123]

Hello. I have a relais board attached to my Colorlite 5A-75B. When I turn on the maschine, the outputs from the colorlite are LOW. So, all the relais are turned on. And therefore my coolant starts running 😄

Is it possible to set the default output to "HIGH"?

I tried to find a line of code in the "/config/modules/gpio.py" and "/firmware/modules/gpio.py" but I am not that familiar with this 😃

When I start LinuxCNC I use the "invert_output" param to turn the relais off. But it would be nice to set the outputs to HIGH when the FPGA is turned on

[Peter-van-Tol]

Nice request! This is also a safety issue. What will be the state of an output when not being actively controlled.

In my machine a low state means of. All my outputs ore sourcing, meaning only voltage is applied to the outputs when the GPIO is driven high. A chose sourcing over sinking, because with sinking you're one short away to inadvertently turning your machine on....

Proposal:

• Add a property default-safe-state to the config. The default of this parameter will be False, so the current behavior is retained when this parameter is not set. For your machine you should set this parameter to True.
• The output will be set to this state as long no message has been received or when ever the watchdog has bitten.

Maybe a signal should be send to the FPGA indicating LinuxCNC is closed, to return the card to a safe condition (no motion, outputs to their default safe state.

[OJthe123]

Thank you for thinking about it!

I also tried another "sinking / sourcing" option for PWM. My friend has a board for analog 0-10V output. But this circuit needs an "inverted" pwm signal. Otherwise 10% pwm leads to 9 Volt, and 90% to 1 Volt.

I edit the files to add an "invert_output" pin. The pin is created in LinuxCNC. But it seems the state of the pin is not transferred to the FPGA correctly. I can force the inverted output when I set "default_invert_output = 1" in the firmware/modules/pwm.py. So this kind of works already. Maybe you can have a look and find my mistake.

pwm.zip

[Peter-van-Tol]

Progress:

• [x] Created branch to test the code in;
• [x] When LinuxCNC exits, the FPGA is reset before the driver is unloaded;
• [x] GPIO out should be in the reset circuit
• [x] GPIO out should have a safe state
• [x] Documentation

[Peter-van-Tol]

@OJthe123 : the invert_output pin for GPIO is done in software. It negates the required bits before sending them to the FPGA, there is no data send to the FPGA, it's done in this line (litexcnc_gpio.c:125):

 *(*data) |= (*(gpio->output_pins[i-1].hal.pin.out) ^ gpio->output_pins[i-1].hal.param.invert_output)?mask:0;

To invert the PWM, no modification is required. Just apply a negative scale and apply an offset to get the correct value. For example:

• value of 0 should be 100% duty-cycle;
• value of 100 should be 0% duty-cycle;

This results in scale = -0.01 and offset=100 to get the behavior you want.

[Peter-van-Tol]

The feature is finished, it improved the project a lot. Thanks for the request.

@OJthe123 : Could you please test the feature and let me know if it is also working for your situation? The branch is 29-default-state-of-output-pins. Documentation on the safe_state parameter can be found in the GPIO documentation under configuration.

[OJthe123]

Hey. Thank you! That was quick!

The safe-state works perfect!! :smiley:

But with this drivers I get the motor position errors...

[Peter-van-Tol]

Did you try a reinstall of the drivers? The position following error should have been resolved. I can jog now with 1500 mm/s without problem.

Can you zip your Hal configuration and json? Then I can look into it this evening. Either I can provide you with a working config or it is a good benchmark to improve the driver.

[OJthe123]

Yes. I reinstalled the drivers and rebuild the firmware.

I could fix this because the project is based on modules 😃 I copied the new GPIO module to my working branch and reinstalled drivers and firmware again. Now it works all together 🚀

EDIT: here are my files https://www.dropbox.com/scl/fi/lzqu1xbe2nys3r1atepuf/Semse.7z?rlkey=2ya6vzyd4u88tnoi1n6rjiyg6&dl=0

[Peter-van-Tol]

Can you also add your .json-file. My connection to the FPGA is fixed to the 10.0.0.xxx range of addresses and you use another range. Therefore I have to recompile your firmware in order to test it.

I've a hunch where the positioning following error comes from. You use in your HAL-file the pin [LITEXCNC](NAME).stepgen.##.position-feedback. This pin contains the actual value when the parameters are read from the FPGA, not where the machine is at the end of the current step. LinuxCNC expects a value where the machine will be at the end of the cycle (i.e. the FPGA is lagging one cycle), which is contained in the parameter [LITEXCNC](NAME).stepgen.##.position-prediction.

When acceleration is large, the difference where the machine is when the FPGA is read and where it should be at the end of the cycle is too large, thus you get a position following error.

Could you try and replace the pins [LITEXCNC](NAME).stepgen.##.position-feedback with [LITEXCNC](NAME).stepgen.##.position-prediction?

[Peter-van-Tol]

Closing this issue, because the safe_state is implemented. Please feel free to use this issue to discuss the positioning following error further or share your config.

[OJthe123]

semse.json.txt

Here is the JSON.

I will try to change the hal pins the next time....

[Peter-van-Tol]

Great (?) I can reproduce now. Will take my findings to #28 ...