PDA

View Full Version : Arduino Grbl UGS



electrosteam
17th Jun 2016, 05:31 PM
I have a thread running in the Woodwork Forum about a router at my local Men's Shed that uses an Arduino with Grbl as the operating CNC driver, with Universal Gcode Sender on a laptop to command the machine.

We are having a ball getting it running and we are '' nearly there''.

This thread is simply to see if there are any others out there that would like to swap suggestions/advice/stories/warnings etc on this combination of hardware and software, or closely related.

Please, don't jump on me about your favourite packages or other suggestions for alternatives.
We have what we have, and the computer side of things is not our limiting factor, at least for the moment.
But, there are few 'interesting' things that are worthy of discussion.

John.

RayG
18th Jun 2016, 05:27 PM
Hi John,

Do you have any pictures of the machine?

Ray

electrosteam
18th Jun 2016, 06:55 PM
Ray,
Here is a photo.
The machine is a ShapeOko, not sure what model/vintage/sub-species.
The hardware/software combination seems to work Ok, but there are a number of deficiencies, I believe.
The Arduino appears to be widely used in bottom-end applications because it is cheap and easy to get going.
I have even seen references to possible applications in higher-end machines - something I would not recommend.
362843
John.

Markvdesign
18th Jun 2016, 10:30 PM
G'day John, I'm currently in the process of building a cnc plasma cutter that will use an Ardunio Uno, CNC Shield v3 running GRBL. I'm currently working on the x axis and some motor mounts for the y. It is going to be interesting how it performs especially once I introduce EMI from the plasma. I also have plans to be able to replace the torch holder with a router but I reckon my gantry will lack rigidity.


Sent from my iPhone using Tapatalk

RayG
19th Jun 2016, 12:47 AM
Ray,
Here is a photo.
The machine is a ShapeOko, not sure what model/vintage/sub-species.
The hardware/software combination seems to work Ok, but there are a number of deficiencies, I believe.
The Arduino appears to be widely used in bottom-end applications because it is cheap and easy to get going.
I have even seen references to possible applications in higher-end machines - something I would not recommend.
362843
John.


Motion control systems are always fun to play with, looks like you are having a good time with it. :2tsup:

What's the spindle motor?

electrosteam
19th Jun 2016, 09:43 AM
Mark,
Before you commit wiring, make sure you have got the latest documentation.
They swapped the pin allocations D11/D12 when they went from Grbl0.8 to 0.9j.
Note also the pin designations start at pin 0.
Frankly, both of these issues smack of a juvenile design approach.

The recommendations for capacitor input filtering place an interposing home-made PCB between the Arduino and Shield, making an unwieldy stack that is very difficult to fault find.
On our router, the CNC Shield heatsinks are borderline at best.
The Shed builders attempted to integrate the wiring, better (in my view) to bring all the field wiring to a terminal strip at the control cubicle.
Include an emergency stop/reset of the Arduino itself, I have not researched this yet so I cannot advise details.

Ray,
The motor is about 48 Vdc, more details later.
John

PDW
21st Jun 2016, 09:06 PM
Mark,
Before you commit wiring, make sure you have got the latest documentation.
They swapped the pin allocations D11/D12 when they went from Grbl0.8 to 0.9j.
Note also the pin designations start at pin 0.
Frankly, both of these issues smack of a juvenile design approach.

The first, maybe, I wouldn't comment except to say that things evolve.

The second just shows a C heritage and it's exactly what I'd expect from serious and experienced programmers. Pretty much *all* the commonly used languages above machine code are derived from C. It works, it's easy to program and zero base is much nicer to deal with than 1 base for loops and other control systems.

PDW

electrosteam
21st Jun 2016, 10:13 PM
PDW,
Its not the software I complain about, it is the pin numbering.

There are good theoretical reasons why a system of numerical analysis should start with '0', and software design follows this to good effect.

Ever since vacuum tubes were developed in the first days of the 20th century, pin numbering has started with '1'.
Every microprocessor PCB I have seen starts the pin numbering from '1'.
The pins on the various chips, buses and connectors on personal computers start at '1', and it goes on.

Labeling a pin on a PCB as 'Pin 0' just maximizes the probability that a user will get the wrong pin when numbering off.
It is contrary to 100 years of development of complex systems with numbered physical interconnections.

The documentation should use terminology similar to 'Data 0' on 'Pin 1'.

As for the D11/D12 swap, consider:
Someone elected to engineer an interface between a microprocessor and a CNC machine that left out a PWM output, knowing that virtually all equivalent commercial systems include a variable speed output for spindle control.

I think my labeling as 'juvenile' on both issues is deserved.

John

Markvdesign
21st Jun 2016, 10:48 PM
Mark,
Before you commit wiring, make sure you have got the latest documentation.
They swapped the pin allocations D11/D12 when they went from Grbl0.8 to 0.9j.
John

Thanks for the info John, I actually ran into that problem when connecting up the limit switches. I've managed to add a probe and E-Stop using the existing pins on the shield. All seems to work well.

I'm only very new when it comes to electronics but have some basic understanding of them and work as Front End Web Dev so the installing/programming side of things is easier.

I'm uploading videos on YouTube of the build and would love to hear your feedback.

link => https://www.youtube.com/playlist?list=PLkPDurmnklNzo8r5llYL07SMppKR2X-Fr

electrosteam
26th Jun 2016, 11:32 AM
I reported in the Woodwork Forum that we (Shed members) could not quite understand how to zero out the work and machine coordinates.
We have our own solution that involves powering down the Arduino.

I have done some research about this issue on the UGS development site and there have been a couple of subjects declared as bugs by the developers that are currently being improved.

It could be that UGS V2.0, expected 'soon', could provide better labelling, better actions and better descriptions.

John

RayG
29th Jun 2016, 06:08 PM
I reported in the Woodwork Forum that we (Shed members) could not quite understand how to zero out the work and machine coordinates.
We have our own solution that involves powering down the Arduino.

I have done some research about this issue on the UGS development site and there have been a couple of subjects declared as bugs by the developers that are currently being improved.

It could be that UGS V2.0, expected 'soon', could provide better labelling, better actions and better descriptions.

John

Normally you have limit switches at the home position, you drive each axis to the limit switch and zero that axis. It may be that your limit switches aren't wired up correctly.

electrosteam
2nd Jul 2016, 07:43 PM
Ray,
I agree that we should have a homing procedure.
We have correctly operating limits on X and Y, the Z limits are temporary victims of the software revision.

When we re-wire into a bigger box with proper field wiring terminals I will ensure that allowance for homing limit switches is included, and the Z limits are fixed.

Not sure if dedicated switches for homing are required, or simply use the travel limits.
The more hardware, the higher the failure rate.
What way is going to be more reliable for multiple inexperienced guys in a Shed ?

For UGS, the available controls are just a little ambiguous and I hope the next revision will go some way to resolving the issues.
UGS does have a 'Return to Zero' control, this may be intended to be a homing procedure.
But, none of the UGS documentation I have seen includes any description of such a homing procedure.

John

electrosteam
13th Jul 2016, 06:54 PM
Experimenting today demonstrated that the built-in homing procedure works fine for the X and Y axes, but there is a bug in the UGS Z axis movement.

The homing seems to be a lift of the Z axis to some sort of clearance height, then a rapid move to the location shown on the UGS screen as Work Coordinate X=Y=0, finishing with a drop of the Z to Work Coordinate Z=0.

But, the Z axis lift seems to be equal to the current Machine Position Z axis coordinate.
If, for example, the current Z axis Machine Position is Z=15, the Homing Sequence lifts to Z=30.
This potentially is very serious as we still don't have Z limits operational.

We tested this effect on several occasions and are comfortable that it really is a bug.
I will research again the current list of bugs to be corrected in the next release of UGS.

John

electrosteam
13th Jul 2016, 09:45 PM
Correction to the above.

What we were actually doing was "Return to Zero" not Homing.
I think Homing requires exercising of the limit switches, not yet tested.

Sorry about any confusion,
John

electrosteam
16th Jul 2016, 06:23 PM
Research today found that "Return to Zero Runaway" has been declared a Bug by the UGS code writers.

There is a description of some of our investigations on the Woodwork Forums, Men's Shed Router - Page 5 (http://www.woodworkforums.com/f170/mens-shed-router-203802/5).

John.

electrosteam
22nd Aug 2016, 06:52 PM
I have spent some time trying to set Work Coordinate Systems, or WCS.

On my Jaycar Arduino clone running Grbl 0.9j on a desktop with UGS on a laptop, setting WCS in conjunction with cutting code is risky.

WCS are persistent over comms Close/Open and power Off/On cycles, and take a very significant time to burn the value into the EEPROM.

The only reliable way foward is to either:
- set WCS using the UGS Macro facilty,
- run an entirely separate program just to set up the WCS.

Note that I am referring to the G10 L2 variant used to preset WCS.
The case of jogging the machine to the desired origin position of the work envelope and calling the G10 L20 variant is a different case not explored by me.

John

electrosteam
23rd Aug 2016, 04:39 PM
I posted the same subject of WCS setting on the ShapeOko Forum, The Shapeoko Forum • View topic - Work Coordinate System - Values (http://www.shapeoko.com/forum/viewtopic.php?f=3&t=8297) .

Included are some interesting observations and clarifications.

John

electrosteam
15th Sep 2016, 08:38 AM
A couple of things discovered:
- Pause/Resume in UGS works fine without missing steps,
- the Z axis can be adjusted by hand while energized (and stopped),
- Z axis scaling is very close to 0.01 mm per 'click'.

The above allows us to adjust height in the middle of a job.

John