OpenBuilds CONTROL Software

Why is a G0 Z5 command sent when I click on the gotozero for xyz button? I'm on version 1.0.133

[13:46:58] [ G0 Z5 ] ok
[13:46:58] [ G0 X0 Y0 ] ok
[13:46:58] [ G0 Z0 ] ok

 

If you are at say X200 Y200 Z0 already, without a hop it scrapes the stock

 

that should really be a G53 move that lifts Z as high as possible before moving.
this will then clear (at least more likely!) any clamps and fixturing.
G53 G0 Z0
G0 X0 Y0
G0 Z0

of this does hinge on the machine being turned on with Z high to mimic homing

 

Peter: Got it. Is this adjustable or perhaps use David's suggestion? Typically this wouldnt be an issue, but I had a situation yesterday were my work z0 was 3mm from my limit switch.

 

Will give it some thought... always that fine balance between "easy for beginners" and "you guys already know what you do hehe" - and the overhanging "no configuration" mandate (sometimes I feel like caving in and just adding a config, but its so wrong hehe)

 

Right. I keep forgetting that. But still seems David's suggestion ticks off all boxes

Are you getting frustrated with me yet? LOL

 

Not at all man! Never will! Just got to think about this one.

G53: As this ecosystem is very modular, theres some assumtions one cannot make. If this was a commercial machine company, we'd know they all ship with limits and we'd know where all the jigs and clamps were so we could dodge them, etc, and we could actually use mPos for a lot of useful things. But as its modular, you're gonna have guys without limits, so mPos is an unknown area... Remembering to turn machine off in certain locations, something many will forget by day 2. Thats where these sort of things get tricky. As each person comes up with his/her own ideas for machines, "standards" even become murky. It's really a hard place to work in and keep everyone happy.

We can talk to the machine, so perhaps it might involve a plan like looking to see if you have hard limits enabled (and have homed at least once in this session) before enabling G53 instead of something else)

Or, like we do with the "Is this a laser, mill, plasma or all the above?" question (By not hiding options, and rather displaying both options in a dropdown menu) we might consider making that button a dropdown with a few different ways of going to 0,0,0 etc

All rough ideas, given a little time and experimentation will be refined into one that works for everyone

(For now, remember though that each axis has a goto zero in the dropdown to the right of the DRO, you could orchestrate the move from there (Do x and y first, then down to z) (it doesnt hop either as its individual moves)

 

Right. Keep in mind that I'm an only child so I only think about myself and what I need. LOL.

For what its worth, I've considered using other software. Even thought about going with a PathPilot setup since I have it running on my Tormach and I've even written code from them. However, I do like the simplicity that you're striving to keep and I really want to support OpenBuilds in any way I can, even if it means I have to think in metric. I've even refrained from digging into your code to make changes.

 

Didnt know you code. Feel free to make a fork and mess about, even if its just to prove me wrong

 

I believe the right thing to do is to teach users as early as possible that turning on with Z high is the right thing to do, always.
This makes a lot of things 'just work' (like the stock Fusion360 postprocessor Gcode).
The next version of SketchUcam will use G53 G0 Z0 moves, these are industry standard things and we cannot ignore them and excuse ourselves with 'but it is just a hobby'.

I set a macro button in bCNC to do a 'goto WCS' and I just press that before shutdown. I never forget (-:
(and if one does one is quickly reminded by a crash that operating the machine correctly is important)

If I have a power failure I just push the gantry to right/back and turn Z to the high position and when power comes back I can resume the job. I call this 'virtual homing'. Works everytime. (yes, on a leadscrew machine one would have to jog and then reset GRBL, easy enough) (or use an electric screwdriver to run to the ends)

 

So went with this kind of logic. Still don't (can't) make assumtions that people parked their Z manually, so instead I am looking for $21=1, and $22=1 before enabling the menu item:

Without limits:


and With Limits



While I was at it, also added (for all three axes)


Will be in 1.0.134 or newer (internal testing pending)

PS: That menu is now a thing, so if you need other ways, do ask

 

lol! They warned me against this career! Now I finally understand!

Usually the group is called 'dialout' (on Ubuntu, Pi, most other Debian and SuSE based distros) but of course Manjaro is being different (; [no intention of starting a distro war - any ensuing fires is purely coincidental lol]

Found How do I access a RS232 serial port in manjaro) where they said
"I found that Manjaro has group for serial pots called uucp. So at first I tried gpasswd -a kb uucp and got permission denied but then I remembered to put the sudo in front of it and I was added to the group. So I tried cutecom and putty again same thing unable to access serial port. So I restarted the laptop and I could get into the router."

 

Peter, what if the last job run issued a G20?
Then the G0 Z5 will try to move 5 inches, ensuring a crash on most routers!

 

Good catch, will throw a G21 and G90 in before

 

Hi James

Are you sure the skipping isnt related to stepper drivers overheating? The XPRO v4 has a feature called DriverMinder that puts Grbl in 'hold' status when the drivers overheat (I don't think we are catching those in software yet - as thats new on the V4, but thats beside the point for now, as the root cause is the issue, not the secondary symptoms - will address in future) , it shouldnt overheat in the first place - add cooling fan, and adjust current potentiometers appropriately (All the way open, will overheat)



To test if it is DriverMinder putting Grbl into a Hold status, slide the Action on Fault switch to [play]=resume (This effectively ignores the DriverMinder signals)

Once you no longer overheat the chips, they'll no longer throw Grbl into 'hold' status


(I'll add some support to the software to better handle it once it happens, but the important thing is it shouldnt happen in the first place - once that driver overheated you already lost steps. DriverMinder in practice isnt going to help at all (the pause function) - aborting is the only thing to do after you already skipped steps)

 

Heads up that the xPROv4, and PowerCase has their own threads CNC xPRO V4 and OpenCase Mounting Kit respectively, where the awesome comments might gain better visibility than deep inside the CONTROL software thread (;

 

V1.0.135 now sends G21 G90 before the moves. See what you can break next hehe

@email.james.home - v1.0.135 now also catches the pinchange notifications from Grbl and pauses the frontend too once the firmware is triggered (So you'll see the frontend pause when driverminder pauses it)

For those without DriverMinder, this also catches the FEEDHOLD/RESUME/ABORT buttons that can be wired to any Grbl board (see Connecting Grbl at gnea/grbl )

Compiling now, will be available in a couple mins

 

and what would be really nice is continuous jog the way candle does it.
hold down the button and it moves at a selectable rate. release the button and it stops.

 

As part of the keyboard/gamepad work I already wrote the continuous jogging code, so that might happen soon. Can be tied to the UI buttons too.

Re Z Jog distance, hard to add seperate distance selector to ui without cluttering.

 

All we do is report what grbl says. So if grbl says Pn:H then something is pulling its hold pin to GND. Ie Hardware. (we pretty up Pn:H into a more English warning, but it is what it is, not OpenBuilds Control)

 

Hey Peter. I was 2 hours into a 2-1/2 hour job last night when the machine suddenly lost its mind and plunged into my stock as far as it could go. The DROs displayed "NaN". I googled it and it means "Not a Number", but I couldnt find a reason why this happens. Can you possibly shed some light here?

 

That would most likely be a USB comms drop / EMI related.

NaN on the DRO means the parser was getting garbage back over serial from Grbl (Ie a string came in over serial, we tried parsing it to numbers, failed because the result was Not a Number)

 

Is there a facility to save your settings? I tried to find one yesterday and one was apparent. And wouldn't you know it, this AM I mistakenly clicked the grbl settings tab. Because the screen didnt change quickly, I thought it didnt register the click on the settings tab, so I clicked the open gcode icon. Well, when the screen refreshed, it registered my click on the "reset eprom" icon and I lost all my settings. Can you add a "are you sure" dialog box to anything destructive?

 

v1.0.137 now asks you to confirm if you hit any of the reset eeprom/settings/wco buttons

 

Awesome.

Is there a way to save my current settings?

 

Not yet, copy paste from Serial Console? (run $$)

 

Great. Thank you.