grblHAL in CNC plasma cutter application

[electroklas]

As I had trouble finding anything written about the usage and settings for GrblHAL in a CNC plasma setup, I'm starting this thread to document what's needed to get it up and running. My intention is to update this first post after getting info and answers to my questions below... The hope is that others can find use of the information.

Prerequisites (my intended hw setup):

• X,Y,Z portal setup, Stepper motor driven, with external drivers (Step/Dir/EN)
• Floating Head (Height probing before each cut is initiated)
• GrblHAL on Teensy4.1 CPU (T41U5XBB)
• ADCI Analog Arc voltage sensing for THC function
• Home/limit switches on X, Y and Z axis, Connected as 'Normally Closed' (for minimised EMI noise sensitivity )
• Floting head / Probe switch (NC)
• Torch Breakaway Switch (NO) (Circuit will be closed when torch is in its holder (and switches are activated), and open when crashed into something)
• ArcOK signal (Contact closure) from Plasma power unit
• Additional Operator Switches: E-stop (NC), Cycle Start (NC), FeedHold (NC), ((E-stop switch definition might be a little bit confusing, but Circuit is closed when E-stop is in running condition, and switch opens when E-stop is pushed in.)
• Firmware downloaded via WebBuilder
• Using ioSender on Win to communicate with board
• Initially via USB, but will switch to Ethernet in final setup

FW Build configuration

• Various settings has to be chosen in WebBuilder tool, To be defined

First discovery's/findings

• You need a running controller board or a simulator to get ioSender up and running, even to start playing around in the GUI. You will otherwise not even get the main window to open.
• With default settings, everything will be locked down initially due to various switch inputs will be in active states, ie E-stop, FeedHold, Limits, and so on. (Can be modified in config settings by inverting various inputs, but better to actually wire them as intended, even if just temporary on the bench..
• Motor Axis signal usage is self exploratory, using X, Y and Z axis outputs to drive standard Stepper motor drivers. So is Limit switch connections..
• SpindeEnable will be used for Arc Initiation signaling (Via external Relay)
• Probe(FloatingHead switch), Breakaway Switch, ArcOn (from Plasma unit) Pins is TBD (Still trying to figure out t41u5xbb board pin mapping versus GrblHal signal names in various locations of the sw system stack.)

To be continued...

(I hope this is a Valid usage of the GitHub Discussions function)

[electroklas]

First round of questions:

• Which GrblHal settings must be altered for a plasma setup?
  -- laser mode ? (If i remember correct, that was used in old grbl controllers)
  --- (I cant set it from ioSender Grbls Settings tab, it always defaults back to normal mode...???)
  ---Edit... Found it in the console view: 'error:17 - Laser mode requires PWM output.'
  --- Edit 2, I remebered wrong, Laser Mode was NOT used in my previous setup

Pin /port usage for plasma application:

• Is there a 'normal' pin map for plasma functions (the BWD board markings are focused on mill usage i believe)
• how do the various port numbers shown in ioSender config tabs relate to inputs and outputs defined in board_map.h files? (EDIT: I might confuse myself, not understanding the nomenclature of the file, ioSender ports might actually just be AUXinput and AUXoutput pins directly.... the usage of direct function names for some things fooled me i guess)
• Can limit Switch inputs A and B be reused for other functions or are they hard coded to the limit usage? (Arc on detect, Breakaway signaling, or similar) ( Edit: I guess it would need me to define a my own board_map file, and move away from the webBuilder and compile the project myself...)
• THC Arc sens port is set to 0, is this valid port for BWD ADCI board( MCP3221 I2C ADC)

[terjeio]

laser mode ?

Not needed, but could be useful for feed hold handling?
Better would be that the plugin handles feed hold cycle start - but how? Run a macro on cycle start to reprobe before arc on? Just turn the arc on and continue? ...?

Is there a 'normal' pin map for plasma functions (the BWD board markings are focused on mill usage i believe)

Not really. It depends on which inputs are available and if other plugins also claim inputs. So configurable.

how do the various port numbers shown in ioSender config tabs relate to inputs and outputs defined in board_map.h files?

Usually 1:1 but sometimes not - this is a headache of mine. Since auxiliary ports can be used by the core (by M62-M68) I want the port numbers visible to it to always start from 0 and be consecutive. These are the Pn and En numbers:

[PIN:36,Aux in 0,Arc ok]
[PIN:30,Aux in 1,P0]
[PIN:31,Aux in 2,P1]

Here port 0 is claimed for the Arc ok input causing the Pn numbers to be shifted.

Another problem is when the map file assign port numbers based the configuration, pins not used for spindle control or limit inputs etc can be added to the pool of auxiliary ports. Again, to keep port numbers consecutive they may be renumbered when registered with the core so referencing the map file for port numbers is not a good idea, the $pins report shoud be used instead.

Can limit Switch inputs A and B be reused for other functions or are they hard coded to the limit usage?

Yes and yes, if the corresponding motors are not enabled and they are assigned as auxiliary pins. I have done that in some map files, typically for MCUs that has limited number of pins. I recently lifted the limit on max auxiliary pins (per type) from 8 to 16 but have not gone through all 50+ map files to optimize pin assignments - perhaps some rainy day when I have nothing else to do I will...

THC Arc sens port is set to 0, is this valid port for BWD ADCI board( MCP3221 I2C ADC)

There are four groups of auxiliary ports, analog in and out, digital in and out. Port numbers starts from 0 for all of them. So the port number for Arc ok (digital in) and Arc voltage (analog in) can both be 0.

[ahmadmadary]

I resently made a CNC plasma cutter with grblHAL and btt skr pico board. I am using iosender to send code to the controller. but i cannot find a way to automatically probe the surface using the floating head and update the coordinates (for example G54).
Manually, i can probe the surface and update the G54 in the iosender, but not automatically.

Can i ask you how you do it? is there a way to do it?

[electroklas]

Thanks Terje,
I'm not sure i understand the mapping 100%, but at least it shows that the source of my confusion has reasons..... ;)
Pn & En numbers? (Nomenclature that misses me)

[terjeio]

Pn and En numbers are used by M62-M68 to reference the digital or analog port to be used for the command. E.g. M62P0, M62P3, M67E0 etc.

[electroklas]

but i cannot find a way to automatically probe the surface using the floating head and update the coordinates (for example G54).
Manually, i can probe the surface and update the G54 in the iosender, but not automatically.

Can i ask you how you do it? is there a way to do it?

I have not reached that stadium yet in GrblHAL, but it worked ok in my old GRBL setup...
My toolchain then was: Fusion360, OpenBuilds Plasma/Laser Post, OpenBuild Control Gcode sender.
I ran without limit switches (No homing) and just set x and y axis to zero at a good starting location on the material...
The post had functions for initiate probing... it just sets the z-axis to zero at probe trig.....

an excerpt from some notes of mine on how the generated g-code around probing looked like:

G54				        Work Offsets
G53 G0 Z-10			Move in Machine Coordinates (G53 is not Modal) Backing off Z 
G0 X28.396 Y9.83 F1000	Linear Move (Rapid) (to cut position)
G0 X28.396 Y9.83 Z15

G38.2 Z-30 F100		Probe Z (in direction and length: -30, at speed F100) 
G10 L20 Z-1			Set curret Z coordinate to -1 (compensating for probe switch offset)
G0 Z4				Go to Pierce Height
M3 S1000			Turn Plasma on
G4 P0.5			        Dwell for 0.5s, (PierceDelay)
G1 Z1.5 F1000		        Move to Cutting Height
G1 X30.896 Y5.5		Cutting movements