grblhal / plugin_plasma Goto Github PK

Sorry for putting this in issues - there is no discussion section.

The current ADC daughter board I make has 12 bit resolution. Is 10 or 8 bit resolution acceptable? When I started out I assumed that 12 bits was needed but am not so sure.

Assuming a target Arc Voltage of 100V, 12 bit resolution means 24 mV per step, 10 - 96 mV/Step and 8 - 391 mV. This assumes no noise so the reality is probably 3 to 4 times worse usable resolution, with an 8-bit ADC probably reaching a volt per step. (disclaimer, I'm no analog guru).

The reason I am asking is I've been looking at alternate ADCs. The current MCP3221 is relatively expensive and seems to have limited/sporadic availability. There is a 10 bit ADC - MCP3021 that looks like it is a drop in replacement for the MCP3221. It appears to have broader availability and is a bit cheaper. The current driver in grblHAL should work with no changes. It yields a 12 bit value but the bottom 2 bits do not get set. The datasheet does not define what they are set to but as long as it is consistent, it should not matter. I've got a couple on order and will try them out. The nice thing about the MCP3021, it has the same I2C address as the MCP3221 so no driver changes needed.

I've also been looking at several TI ADCs that have broader availability. They are well less expensive than the MCP3221 but require driver changes. Probably small but still needs to be considered.

Hi!

If we wanted to use a THC with the OpenBuilds BlackBox, what would your suggestion be?

The THC we have an eye on can use Mode 2:

With the ports available on the BlackBox, we don't have three "spare" inputs for Arc OK, Up and Down.
But - we might be able to cheat like we did with the parallel limits we did for the 4th axis with the plugin https://github.com/grblHAL/ESP32/blob/master/main/BlackBoxX32.c

In this case we might be able to get away with the available ports if we:

• Wire X, Y and Z switches all three to X input - use seperate homing sequences to home Z first, then X and then Y, using plugin similar to how we did the 4th axes / autosquare shared input to have them all share one input.
• This clears up Y and Z limits input - the (optocoupled) port expects SIG closing to GND to activate - which works great with relay output THCs like the PromaSD and others - so we can use those two inputs for the UP/DOWN signals
• The rarely used DOOR input can be used for Arc OK (Or could we have the ability to bypass Arc OK for the cheaper machines and just use a G4 at your own risk if it fails to ignite - would accomodate the cheaper plasmas without a CNC port (Proma's voltage divider provides divided voltage sense to the THC, but no arc-ok)
• Probe port is still available - so you can do material touch-off probing at the start of each cut to set initial heights (compensate for warp even before you can the THC, by touching off prior to piercing)

Doesn't need an analog input as the THC handles the voltage sense side itself and just sends up/down and arc-ok (from the Inverter)
So #2 (comment) might apply as well, we'd be forced to only support Mode 2 THCs due to our hardware - but we can document that clearly

OK, my hardware is not fully operational, so that may be the source of the issue. Much of what I'm doing at this point amounts to simulation with relays and wires.

I have a 5v relay connected to the spindle enable on the Teensy 4.1 T41U5XBB. When I toggle spindle on ioSender, the relay closes (which is expected) and then opens a few seconds later. This part of the behavior is similar whether the connection is USB or ethernet.

Now for a bit more.

1. if connected via USB, ioSender (2.0.43) shows "arc on" in the status bar. It doesn't change to "arc ok," "arc failed," or "arc delay." I have the "arc ok" port set to [PIN:30,Aux input 1,Arc ok] per $pins which is correct. I was thinking of simply hardwire AUX1 to 3v3 to simulate "high" (or setting to gnd for "low"). The plasma cutter "arc ok" is not much more than a NO circuit that is closed by Cutter. Hence the idea of either jumper to 3v3 or GND. This doesn't change the behavior. Then ioSender will popup a message with "Unhandled exception occured: Object reference not set to an instance of an object" then ioSender closes.

2. if connected via ethernet (which will be my preferred connection), no "arc on" in status bar with similar msg from ioSender.

Am I "simulating" the "arc ok" incorrectly? Is there a way to query the current status of the AUX digital pins from console?

I apologize in advance if this is not truly an issue.

Tried several time by adding the THC plugin on the web builder, but the firmware generated did not include the THC .
also like to know where all the control lines from the CNC Plasma cutter connect to on the phil-barrett breakout board, can not find any documents on that. Thanks,

Hi, I am a developer, I am working on a plasma right now. I intend to use grblHal with Atmel SAM3X8E (Arduino Due) as base hardware. I have doubts about how to add the Plasma / THC plugin to the main project? also if you are interested in testers and developers I like to be one . Thank you very much in advance.

Hi, I am trying to use the PicoCNC board with the RP2040 for a DIY plasma cutter and am trying to get THC working. The analog input will be the ADC on GPIO28, moving the probe pin to 24. I also ordered an I2C ADC chip but that's a later step.

However, I am immediately running into problems while trying to add the plasma plugin. I added an include "plasma.c" within driver.h but it contains redefinitions of multiple functions causing the compilation to fail. (side question: why was the plasma.h file removed in some recent change?) In summary the errors are for redefinitions of the 'digital_out', 'analog_out', 'stepperPulseStart', and 'enumeratePins' functions, and for the 'settings_changed' variable. Here is the full output:

....
[ 17%] Building C object CMakeFiles/grblHAL.dir/ioports_analog.c.obj
/home/jelmer/grblHAL_driver_RP2040/pico_cnc.c:51:13: error: redefinition of 'digital_out'
   51 | static void digital_out (uint8_t port, bool on)
      |             ^~~~~~~~~~~
In file included from /home/jelmer/grblHAL_driver_RP2040/driver.h:207,
                 from /home/jelmer/grblHAL_driver_RP2040/pico_cnc.c:26:
/home/jelmer/grblHAL_driver_RP2040/plasma/thc.c:137:13: note: previous definition of 'digital_out' was here
  137 | static void digital_out (uint8_t portnum, bool on)
      |             ^~~~~~~~~~~
make[2]: *** [CMakeFiles/grblHAL.dir/build.make:202: CMakeFiles/grblHAL.dir/pico_cnc.c.obj] Error 1
make[2]: *** Waiting for unfinished jobs....
/home/jelmer/grblHAL_driver_RP2040/ioports_analog.c:89:13: error: redefinition of 'analog_out'
   89 | static bool analog_out (uint8_t port, float value)
      |             ^~~~~~~~~~
In file included from /home/jelmer/grblHAL_driver_RP2040/driver.h:207,
                 from /home/jelmer/grblHAL_driver_RP2040/ioports_analog.c:22:
/home/jelmer/grblHAL_driver_RP2040/plasma/thc.c:159:13: note: previous definition of 'analog_out' was here
  159 | static bool analog_out (uint8_t portnum, float value)
      |             ^~~~~~~~~~
In file included from /home/jelmer/pico/pico-sdk/src/common/pico_base/include/pico.h:33,
                 from /home/jelmer/pico/pico-sdk/src/common/pico_time/include/pico/time.h:10,
                 from /home/jelmer/grblHAL_driver_RP2040/driver.c:31:
/home/jelmer/grblHAL_driver_RP2040/driver.c:1048:33: error: redefinition of 'stepperPulseStart'
 1048 | static void __not_in_flash_func(stepperPulseStart)(stepper_t *stepper)
      |                                 ^~~~~~~~~~~~~~~~~
/home/jelmer/pico/pico-sdk/src/rp2_common/pico_platform/include/pico/platform.h:265:76: note: in definition of macro '__not_in_flash_func'
  265 | #define __not_in_flash_func(func_name) __not_in_flash(__STRING(func_name)) func_name
      |                                                                            ^~~~~~~~~
In file included from /home/jelmer/grblHAL_driver_RP2040/driver.h:207,
                 from /home/jelmer/grblHAL_driver_RP2040/driver.c:44:
/home/jelmer/grblHAL_driver_RP2040/plasma/thc.c:362:13: note: previous definition of 'stepperPulseStart' was here
  362 | static void stepperPulseStart (stepper_t *stepper)
      |             ^~~~~~~~~~~~~~~~~
/home/jelmer/grblHAL_driver_RP2040/driver.c:1764:6: error: 'settings_changed' redeclared as different kind of symbol
 1764 | void settings_changed (settings_t *settings, settings_changed_flags_t changed)
      |      ^~~~~~~~~~~~~~~~
In file included from /home/jelmer/grblHAL_driver_RP2040/driver.h:207,
                 from /home/jelmer/grblHAL_driver_RP2040/driver.c:44:
/home/jelmer/grblHAL_driver_RP2040/plasma/thc.c:120:29: note: previous declaration of 'settings_changed' was here
  120 | static settings_changed_ptr settings_changed;
      |                             ^~~~~~~~~~~~~~~~
/home/jelmer/grblHAL_driver_RP2040/driver.c:2066:13: error: redefinition of 'enumeratePins'
 2066 | static void enumeratePins (bool low_level, pin_info_ptr pin_info, void *data)
      |             ^~~~~~~~~~~~~
In file included from /home/jelmer/grblHAL_driver_RP2040/driver.h:207,
                 from /home/jelmer/grblHAL_driver_RP2040/driver.c:44:
/home/jelmer/grblHAL_driver_RP2040/plasma/thc.c:656:13: note: previous definition of 'enumeratePins' was here
  656 | static void enumeratePins (bool low_level, pin_info_ptr pin_info, void *data)
      |             ^~~~~~~~~~~~~
make[2]: *** [CMakeFiles/grblHAL.dir/build.make:244: CMakeFiles/grblHAL.dir/ioports_analog.c.obj] Error 1
make[2]: *** [CMakeFiles/grblHAL.dir/build.make:90: CMakeFiles/grblHAL.dir/driver.c.obj] Error 1
make[1]: *** [CMakeFiles/Makefile2:1511: CMakeFiles/grblHAL.dir/all] Error 2
make: *** [Makefile:91: all] Error 2

What would be the correct way of activating the plasma plugin? You mention testing this plugin already so i am also curious about the implementation that you use. I can't seem to find a complete example of the implementation within any of the hardware drivers.

Also, should STEP_INJECT_ENABLE be enabled to use THC?

My fork of the RP2040 driver can be found here for reference: https://github.com/JelmerV/grblHAL_driver_RP2040