Input pin discussion

[phil-barrett]

I think this is a discussion topic until it gains a bit more form and becomes a feature request.

As I think about new breakout boards to design, I would really like to know how many inputs to plan for in order to reach the broadest possible user base.

@terjeio and @einencool have been talking about the door pin in issues.

But then please make it configurable, because I use the safety door as a „pause Option“ with spindle stop :-)

Sure will, if the safety door option is enabled it will have priority. Repurposing the door pin would be a workaround until boards/drivers can get a dedicated override pin. There are other inputs that could be added too - probe connected, block delete, optional stop... These would require board and driver support. The core is already (partly) ready to handle them.

I think this is an important discussion to have. I have been looking at professional controllers and a lot of them have a set of general inputs that can be configured how ever you want. Grbl went a different route and defined specific pins for specific functions. Perhaps it was short term thinking but that made it easy for the hobbyists to know how to hook it up. But the flexibility of having a bunch of input pins that can be assigned to any available function is very desirable. In some ways we are already there with the ability to specify pin assignments in a map file.

My question is what inputs are needed?

Currently, we have in the grbl/gnea fixed function way of thinking:

• up to 6 limit pins
• door, estop, hold, start
• probe

on my 5 axis board there are 10 inputs - 5 Axis limits plus door, estop, hold, start and probe

There is code for limit min and max pins and I believe a home pin per axis though I think that is mostly unused. In the Grbl world, I have only seen two designs out of hundreds that use min and max and none that have a separate home pin. What is the use case for Min and Max? I believe the drivers know which direction triggered a limit so the switches/sensors can share a single pin per axis. I saw the autosquaring case for a limit for each of the ganged motors but I still don't quite understand the need for a separate home input for the axis.

I have seen requests for multiple probe inputs.

Are there others?

In addition, there are quad encoder, spindle sync and other pins. Given that these may need to be reasonably high speed, they probably require different interface circuitry and careful assignment to processor pins.

[einencool]

Hi @phil-barrett ,

Sorry for my late reply, but yes, you‘re right, in GRBL it seems, that only the assigned pins could be used and the possibility to map them as desired are not very good.

With my old machine, I had a look at the Software „EstlCAM“. It‘s based on the Arduino and has an other core GRBL, and so in the software it was possible to map the Pins to the function you want. Also it was possible to set two inputs for two different probe types. That was the reason, I asked for two different input pins for the probing.

It would be a nice to have also different inputs for min and max endstops, but I really don‘t know if this would be necessary.
On my machine I‘ve wired the NC switches in a row, so the wiring is much easier with one input pin for min/max.

I‘m interested how this discussion will go any further.
Maybe we will be able to map some pins with other functions, that would be great :-)
Greets
Chris

[terjeio]

Here are the input signals currently supported by the core:

grblHAL/grbl/system.h

Lines 114 to 133 in 4627412

	typedef union {
	uint16_t value;
	uint16_t mask;
	struct {
	uint16_t reset :1,
	feed_hold :1,
	cycle_start :1,
	safety_door_ajar :1,
	block_delete :1,
	stop_disable :1, // M1
	e_stop :1,
	probe_disconnected :1,
	motor_fault :1,
	motor_warning :1,
	limits_override :1,
	unassigned :3,
	probe_triggered :1, // used for probe protection
	deasserted :1; // this flag is set if signals are deasserted. Note: do NOT pass on to Grbl control_interrupt_handler if set.
	};
	} control_signals_t;

In addition the core has support for limit switches for all axes and separate home switches too. Min and max limit inputs are "wired together" in the driver when available, and min inputs are used as home inputs when not provided separately by the driver.

There are two options for mapping a pin to a function:

• at compile time - easiest to code as no additional settings are needed. Some drivers has support for mapping a couple of pins already.
• at run time - settings are needed for routing input pin to function. Extra code for this routing has to be added to each driver if not signals handling in the core is rewritten to handle a generic bunch of inputs so that routing can be done there.

Both options require additional code, run time configuration (a lot) more. Doable, yes - but not on a whim.

[phil-barrett]

Regarding compile vs run time binding. Clearly, run time binding is desirable but is a lot of work. I doubt anyone expects it anytime soon. Given that Grbl users have lived with compile-time bindings for almost 10 years, I think there are more worthwhile things to work on.

[mjscosta]

Hi to you all, first congrats for the project, there's been a while I was looking for a project like this.

I'll add a bit of story, as all things have one, maybe some of yo already know ...
There's a reason for the pin mapping to be very restricted in the original grbl. The most relevant one was the conservative approach @chamnit used in the grbl project, and on my opinion a great one with very good results, having something that performed well at doing what it does with the resources available.

Grbl was optimized for the 8 bit cpus, and for that reason pins with specific functionality and strict timing requirements where required to be grouped into the same ports, so that it would only take one instruction do change the full set of pins, e.g pwm for the stepper drivers, motor direction and other ... that allowed the the 8 bit AVR processors to perform well and being able to reach faster speeds and accelerations without losing synch.

Then there was another project which I think you guys could really benefit from its learning, dos and don'ts https://github.com/MarlinFirmware/Marlin, this project had a different approach, it was branched from grbl origins not sure which project, but rooted in grbl. Marlin had a hudge community, original also for 8 bits, but a new port was made to support 32 bits for around three years with support for many many features, many many boards. Its main use is for 3D printing, but support for CNC, Laser, Delta geometries, Core XY and maybe others more geometries where added, LCDs, many different display supports where also integrated ...

I've spent some time with a friend of mine trying to use Marlin for Laser engraving using the arduino Due board, but despite the higher frequency and the 32 bit mcu the laser support fails and its not good enough since it loses sych with the laser and the motors. After some time we moved to the 8 bit grbl witch has way less resources and we had great results, no LCD support, no many features, but it does a great job on keeping the movement fluid and the timing of the laser and stepper motors.

But now we hit the speed limits and want to move to 32 bit grbl, hence I'm here.

Marlin has a great structure and their approach and project structure is quite nice, just change some defines in the config.h, if you want to add a new board just add a pin mappings file, and everything just works (most of the time).

But the code is not properly structured in modules, most features are enabled by defines and the code just keeps on growing and hard to maintain ... but it works very well for 3D printing, I'm using it, and tuned it a couple times for the 3D printer ...

Also it has support for PlatformIO and Arduino platform. Maybe this is not the proper place for such a long post ...

I'd like to contribute to this project if there's space for that, so that we can have a proper 32 bit grbl for CNC, and Laser engraving and alike, and stick to that, and do that great, pushing at higher speeds and accelerations.

[terjeio]

I use Marlin for my 3D printer so I know about that project. grblHAL is different since function pointers are used for the HAL and now also for publishing core events. This means that code is actually modular, e.g. a developer can copy the just the core (from the grbl folder) add a driver, and possibly plugins too, and have a working grblHAL system without changing a single line of code in the core.

FYI I have made a dual motion control solution for my CO2 laser, for engraving I send encoded bitmap data - for cutting gcode. This as using gcode for high res engraving is IMO not ideal. The second motion controller code is "pixel perfect" as n steps equals one pixel. There are limitations to this solution though, only a limited set of resolutions are available for pixel perfect engraving.

[mjscosta]

One good thing in Marlin though is the way configure is wired, it works very well to select the board family and enable disable or configure some of the features, now the downside as you mentioned is having defines across all the code instead of the plugin/modular approach but something are not very easy to solve, e.g. pin constraints are not very easy to solve in a generic way, in Marlin its done more less by board family with defines that cause errors at compile time ...

Nice one, well using https://lightburnsoftware.com/ software you can get some nice results for the GCode aproach, though for some materials preprocessing the image and using a black/white pixel approach will provide best results. Not that I'm much experienced in the area. Check this FB group https://www.facebook.com/groups/522775308373490, you can find great ideas an results of a nice community sharing their work and art on the engraving topic. When I have a chance I'll test it, thanks for the tip.

[frdfsnlght]

I just posted a comment over on #130 about limit switch inputs. I think 2 for each axis would be nice (min/max).

Also, I mentioned somewhere else about the use of I/O expander chips to increase the number of GPIO pins using the I2C bus. There's lot's of those available.

[terjeio]

Here is a board with tons of I/O. The STM32F4xx driver can be used as a starting point. Is someone willing to donate one for me for development/testing?

[mjscosta]

@terjeio if you have a patreon account or a paypal or alike I'd gladly donate the board, unfortunately I cannot read from the site you posted.

[Klippert]

Here is a board with tons of I/O. The STM32F4xx driver can be used as a starting point. Is someone willing to donate one for me for development/testing?

Is this still relevant? @terjeio

[terjeio]

Is this still relevant?

Yes, the existing STM32F4xx can be extended for this board. It could become the ultimate grblHAL controller for demanding users?

[Klippert]

excellent. could you ping me your address on [email protected]?

[Klippert]

Hello Phil,

A thought on a new breakout board and input pins.

I would love to see an input for $tpw (it'd be so nice just to push a button and the machine does the probing.)

secondly - i have 4 closed loop drivers, which each has an alarm state (essentially then i crash my machine) - and they are currently all wired to e-stop, so everything stops when that happens. I thought about either having a separate alarm input for each driver - or having a general "motor fault" input.
i also have a compressor for my mister, and sometimes, silly me, I forget to turn it on, so an input for a pressure sensor for "air" would be nice.
regarding probing - it'd be nice to have a "probe connected" so that the spindle doesn't accidentally start up with my new 3d probe in it.
Around probing - i have a 3d touchprobe and a tool-fixture probe, and at present they use the same input. Though i'm not sure if that really makes that much sense?
(It would also mean that the "probe breakout box" that we spoke about earlier, would be less important, as each probe could have it's own input?

Best
Kristoffer

[terjeio]

There are a number of inputs and outputs on the existing board that can be used. The issue is how to route the pins to the desired functionality. One option is to add one or more plugins, others are driver options selected at compile time by #define statements or a run time configurable crossbar for routing. This as there will always be a limited number of pins available, and an unlimited number of ways users will want to configure the controller?

Currently the easiest way out of this for me is perhaps to add more template plugins that can be used as a basis for a user defined one. Options selected by #define statements is going to be a lot of work and will likely lead to messy code - not good.
Having a run-time configurable crossbar, possibly in combination with standard or user defined plugins, would IMO be the ultimate solution. Time for coding, or more coders, is required...

[Klippert]

Cool - so if I were to rewire one of the Aux inputs to an existing input, such as "motor-fault" instead of the emergency stop, would i just be able to change the pin mapping?

$tpw i figure would require some plugin code? - to actually trigger TPW from an aux input?

If I wanted to do a "air check" that would also be something i'd need to write a plugin for, in order to enable such a check on starting a job?

[terjeio]

I were to rewire one of the Aux inputs to an existing input, such as "motor-fault" instead of the emergency stop, would i just be able to change the pin mapping?

Not yet as the aux input code does not support interrupt. This has to be added first.

$tpw i figure would require some plugin code? - to actually trigger TPW from an aux input?

Yes, again this needs interrupt handling for the aux input.

It is possible to get around the currently missing interrupt handling by polling the the input, but that is not an ideal solution.

If I wanted to do a "air check" that would also be something i'd need to write a plugin for, in order to enable such a check on starting a job?

This can be added as a custom M-code if you are able to add that to your post-processor. I have done that for my CO2 laser, if the tube coolant is not detected as flowing within a certain time after switched on an alarm is raised. The code for this is available as a plugin - it is perhaps too complex for your purpose as it supports several parameters for the M-code and monitors the coolant temperature and report it back in the real-time report. Anyway it is an example of what can be done with plugin code.