Advanced Search

I work with a larger community makerspace and people missetting the z and gouging the spoilboard is the bane of our existence,

I would like to implement this:
1.  there's a wireless toolsetter you use as normal to set your top datum jobs.  This is the "User Offset" (UO).  I only mention this to make it clear that the tool offset test is a different thing.
2. a ToF rangefinger on the head.  NOT to try to distance the work, bed, or bit.  Rather, it's mounted above the spindle and if it is not running and senses hands in the area needed to undo the collet nut, it assumes the bit has been changed strobes a "safety touch off required" (STOR) signal that linuxcnc latches.  STOR is basically "tool offset is now unknown, don't run until the tool offset is checked"
3. The safety touch-off is a second toolsetter located in a fixed place on the machine, with a known fixed Z-height above the bed.  The STO cycle finds the z height of the bit tip and scans the loaded file for the lowest Z-coord, applies the current UO, and if it goes below the bed in machine coords, sets Z Safety Lock Out (ZSLO) which locks out the Run mode.  STO test never reorients the job, it only locks out run mode until the user corrects it
4.  Loading a new file, rerunning the wireless toolsetter for a new UO, manually entering a new UO, or running a new STO cycle triggers a reevaluation which could reset the ZSLO.  
5.  STOR is only set upon power-up or the ToF rangefinder detects that the bit  may have been changed.  False triggering the rangefinder and setting STOR is acceptable as it is just a small nuisance, but it should be impossible to interact the with collet nut without triggering STOR.  The corrective measures in #4 do not set STOR since the tool offset is already known.  It is not tested every time you press RUN.  
6.  STO can be initiated manually, or, pressing "RUN" will always trigger an  STO before running, which will either continue on into the RUN mode, or trigger ZSLO and enter the STOP state.

I know this will not protect against bit slippage.  I have wondered about how to do that for awhile, but can't see a solution other than conductive spoilboard.  Conductive spoilboard could actually work, it could still allow shallow excursions into it.  When the spoilboard is grounded by bit contact, the distance from the current Z and the lowest Z in the loaded file cannot be >2mm or we retract Z and stop.

Only problems there are you can't use conductive stock (bypass mode possible), but the main issue would be a cost-effective way to make spoilboard conductive enough.  Then again, if the spoilboard isn't getting consumed regularly, a high-effort way to make it conductive could still be practical.
 

Hello. I've build a setup with ASUS prime N100I-D D4
Turned off some CPU related features in BIOS and added
to linux kernel cmdline params
"isolcpus=2,3 acpi_irq_nobalance noirqbalance"

So Max Jitter(ns) for Base thread is 29725.

Any other optimizations which I've forget about?

Hi,

sorry this this probably a very basic problem but I couldn't find a solution myself: I can jog the machine out of the axis until the limit switch triggers. I have shared home/ limit switches and my understanding was that after homing the machine would know where it is and prevent jogging until the limit is triggered.

I suspect my Home / Home offset /  min limit is the likely cause but as I said I cant figure it out

Currently I tried 
HOME = 5.0
HOME_OFFSET = 0.000000
MIN_LIMIT = -1.0

I also tried 
HOME = 0
HOME_OFFSET = -0.800000
MIN_LIMIT = -1.0

but both still do not prevent me from jogging the axis until i get an limit error at which point I have to restart the machine and manually move the axis free.

Thanks!!

1. whatever you are doing to log all the 0's and 50's , don't, just had to scroll through over 70 pages of it, it is not fun and wastes a lot of very precious time
2. none of the two mentioned errors will not stop the LinuxCNC from running
3. Python error, as noted at the end of a very long error log, having to do with jog buttons as it seems
-
Try using Axis GUI, make the machine work properly by fixing latency issues and the "dolt not cleared" as this will disable the Mesa card completely.
Then try other GUI's.

Solving the realtime delay should solve this? Didn’t consider this as I thought Python did not ran in realtime

So you are saying that the latest stable version is not known to work? It worked great for me...

Shouldnt I try to update the my stable branch first?

Beachten Sie auch, dass bei einem 7I84U beide Feldnetzteile
angeschlossen sein müssen, da er sonst nicht erkannt wird.

Yes, I did.

The surface_scan_param_update.ngc file only seems to handle parameters 3050-3054. These are associated with the ui buttons that seem to work.

github.com/zmrdko/01_surfacemap/blob/mai...can_param_update.ngc

The surface_scan.ngc file mentions several other parameters:
3055, 3057, 3058, 3059, 3060, 3061, 3062, 5061, 5062, 5063, 5403

github.com/zmrdko/01_surfacemap/blob/mai...nes/surface_scan.ngc

I did try adding these to the .var file but that didn't work. Perhaps they also need to be added in a similar way to surface_scan_param_update.ngc?

Another problem is that the instant you try to type a character into the ui boxes for feedrate on the surfacemap user tab it attempts to do something. I.e. It doesn't wait until you enter the value, it tries to send individual characters.

zzrzzr wrote:

When I do a torch-test with 3 seconds pulse then I read a voltage of 180V on the plasmac-screen. Is that a plausible value ? 

Yes it is

zzrzzr wrote:

Is it possible to get a table with cutting-settings for different thicknesses from sb. who also uses a Stahlwerk-Plasmacutter or comparable so I don't neet to try and waste so much metal ?

That will not help you much, you have to do your tests and decide on results as there are to many conditions that will inevitably change the cut quality, like: air pressure, air moisture, nozzle type, cut height, cut speed, type of material (all mild steels are not the same), etc.
Try searching this forum, i have explained several time in detail how to test and adjust for quality cutting.

7i84U ist ein SSerial carte, braucht kein firmware flash.

Subbed with @tomapc and was already subbed with @toma.cnc1 , i think, will also check @toma.3d.

Better late than never but here is a video showcasing Monokrom. I still think this is a pretty impressive GUI, thankls to JoCo..



It would be absolutely amazing if you guys could subscribe to my Youtube channel while watching it. I am 10 short of 1000 subscribers. Its only taken 15 years....

I did a clean install with Linux_Mint_22.1_LinuxCNC_2.10.iso
Linux_Mint_22.1_LinuxCNC_2.10.iso

and now this problem is gone

Befor I did install clean debian 12 and linuxcnc 2.10

Now I can run my peristaltic mist pump at a predefined speed at the press of the coolant mist button or M7 command.

My HALnow includes:
loadrt stepgen step_ type=0,0,0,0,0 ctrl_type=p,p,p,p,v
setp stepgen.4.velocity-cmd 20
setp stepgen.4.steplen 1
setp stepgen.4.stepspace 1
net pump-on iocontrol.0.coolant-mist => stepgen.4.enable
net pump-pulse stepgen.4.step parport.0.pin-14-out

I have been running this HAL code since 2021. It works reliably but these is only one stepper speed available i.e. setp stepgen.4.velocity-cmd 20. If I wish to change the stepper/peristaltic pump speed, I need to edit the HAL file and re start.

Is there a way to add a control to the AXIS control screen or add a pot or encoder the the parport pins which will allow me to change the stepgen speed (velocity-cmd 20) in the HAL file during a machining session.

Thank you very much endian for this converter, I used it and the output "ethercat-conf.xml" file seems correct.