First Post, First Project, & Some Questions

[EddyCurrent]

It looks like the error springs from Pleunum->Guide Slots objects 702,703,704,705 and the diameter of the tool used.
If you make the tool diamter = 0.249 no errors are reported.

[Tool-n-Around]

Before I forget, earlier you asked in post 44 if those runners could be plane sliced to be made in a top and bottom piece. I fiddled about with Freecad and yes you can do this, the only snag was the cut took maybe 20 min's or soto process one slice you would need a fairly newish PC and a video card, I did on my laptop 64bit win ten and it was hopeless.

I’m due for a new PC anyway. When I get to the point of relative proficiency with cb and cutting 2D & 2.5D stuff, I may be ready to get back on the CAD training wagon.

I downloaded your .nc file (to keep your PP settings) and ran it through the simulator it was ok no errors reported. I then ran the code in GRBLMachine in CB (in G20 and G21) (with and without GRBLMachines own PP) and the file ran as expected with no errors. the micro-controller is running the latest version of GRBBLver1.1, the five axis fork on github…………..I went and had a look at the manufactures website again and they are using there own locked in time 4 axis fork.

The controller came with MillRight GRBL version loaded. Why would a custom version be needed and will it likely cause other problems? I’m a bit paranoid about this because of all the soft limits and machine space problems I seem to have. I’m constantly checking to ensure units of measure are consistent. For example, every time I connect to the controller it throws this (header?) at me. I have every setting I know of set to imperial units. Seeing the G21 I issue G20 because all my cb files are in inches. Is it necessary? Or is the controller always in SI and just interprets units per the Gcode instruction?

When I installed GRBLMachine, The XYZ axis displayed in the control panel that sets travel limits, displays in mm. There doesn’t appear to be a way to toggle units there. The numerical values of the limits that were populated in those locations would be correct in mm (875, 875, 90) for the machine, but there is nothing in the XYZ area that indicates units of measure, so initially I didn’t know if it was displaying mm or inches, the latter of which would of course be a problem.

As a last test I ran the file through the GRBLGRU  Gcode sender besides it not liking the tool change it ran through to the end with no errors as well.

The tool change in GRBLMachine was a new wrinkle. At least it has units to select. I take it the XYZ tool change position is relative to G54 work coordinates, correct? I'll need to make tool changes on my next parts in the queue, which may have it's own challenges because I just have a collet in a router, but for now I just want to make sure it isn't the source of problems.

My first though would to be check if the arc's are causing the problem, go to your PP and set your arc output to lines. If this eliminates your errors then the arc's are the culprit and you can then change the Arc output back to arc's and change the variable $12 arc tolerance.

I will check. Thank you.

There is a picture of my test controller GRBL config which runs the posted code as is with no errors.

Sort of goes back to my Q about the manufacture’s custom GRBL version. Not at all anxious to reflash the controller……..when I don’t know what I’m doing.

Thanks again Dave. You help and patience is much appreciated.

Best,
Kelly

[Tool-n-Around]

It looks like the error springs from Pleunum->Guide Slots objects 702,703,704,705 and the diameter of the tool used. If you make the tool diameter = 0.249 no errors are reported.

Thanks Eddy. Just for my own learning and self-help, were you able to determine that from the error report I posted or just further analysis of the file? When I try to run that file, the spindle rapidly travels from the work origin to the top/far Y+ end of the stock, stops, and reports the error. It also puts the machine in Hold. $X wont dismiss it like an alarm which is a royal PITA because I can’t get the machine to release the hold without breaking the connection and restarting the controller…….then I have to home and go through the whole sha-bang again.

But, because of the order of MOPs, and my removing optimization, I at least expected it to perform the MOPs in the order they appeared in the program (as it does on the CAMotic simulations) while I watched the corresponding spindle movements on the UGS screen…….but it does not. Why not? I have another file that does as I expected. It cuts straight tool paths, starts a pocket, and then errors 34 when it arrives at the first arc.

Best,
Kelly

[Tool-n-Around]

There was one more thing I had previously asked. What is the blue space with the red arrow in the attached photo? I was interpreting it as machine space. Is it?

Best,
Kelly

[Tool-n-Around]

Good grief. Now unable to do anything since previous session connecting with GRBLMachine for the first time. Any action results in error that says jog exceeds machine travel. Try to home and says Alarm 9 homing fail. Could not find limit switch with search parameters. Defined as 1.5 * max_travel on search and 5 * pull off on locate phases.

While connected in GRBLMachine, touch pad mouse in largely non-responsive I have to type the error because GRBLMachine does not allow copying the report dialogue. Probably nothing to do with GRBL Machine but USB cable not long enough to get my laptop far enough from the EMI.

I'm sure despite my best efforts to set everything in consistent units I have missed some default GRBLMachine setting. Am now regretting loading the plugin and finding it difficult to express myself without profanity.

I issued a $$ in UGS and the soft limits appear in inches when the text note says mm, so likely the problem but when I try to reset the limits with a a $130 = xx command it errors and says the setting are locked and to contact the machine manufacturer. Then how were they changed in the first place? Via GRBL Machine?

Edit: Exited UGS and was able to re-issue the soft limits from GRBLmachine. Think I'm back in business. At least I can home and jog again

K

[Tool-n-Around]

Minor breakthrough. Got the part to run and air cut for first time. I got it to run from UGS by changing the guide slot width to .001 wider than cutter. I cant get past the tool change in GRBLMachine without error. More later. Copied and saved all my GRBL settings from the successful run.

Best,
Kelly

[EddyCurrent]

Thanks Eddy. Just for my own learning and self-help, were you able to determine that from the error report I posted or just further analysis of the file?

I progressively disabled the machining operations in the tree view until I found the offending objects. It was then from previous experience that I tried reducing the tool diameter.
With diagnostics set to level 4 it's possible to see the errors generated. "Open poly" is a popular error but it does not always mean exactly that.

To disable something in the tree view, first select it so it's highlighted then press the space bar. Further presses of the space bar will toggle the effect.

I see you opted to widen the slots instead, it has the same effect as reducing tool diameter.

[Tool-n-Around]

A little more............I tried to run the file from GRBLMachine but couldn't get past immediate tool change errors. However, on the way, I did elect to overwrite my stored Gcode file with the new version from GRBLMachine. When I opened that GRBLMachine generated Gcode file in UGS, it ran, whereas the CamBam GRBL post generated files would not.....ending with error 33, so I may need to try a couple files to confirm it was just the tool width/guide lsot or whether the post processors also played a role......so fare I haven't gotten anything generated with the cb GRBL to run without ending immediate or early in error 33

So, I thought I'd try to generate a GRBLMachine GCode file for the other part that I have that partially runs but eventually throws error 33 but although GRBLMachine will connect, I can't get my machine to accept commands from GRBLMachine. We'll see what tomorrow brings on that but also, not sure why the GRBLMachine files immediately error on the tool change. I switched tool change to ignore, but since GRBLMachine won't communicate with the controller, couldn't test that.

My first though would to be check if the arc's are causing the problem, go to your PP and set your arc output to lines. If this eliminates your errors then the arc's are the culprit and you can then change the Arc output back to arc's and change the variable $12 arc tolerance.

I still need to try this from one of my cb generated gcode files to see if it will run from UGS.

There is a picture of my test controller GRBL config which runs the posted code as is with no errors.

I saved the config from the successful run for future comparisons.

Not sure if it means anything but the machine controller is loaded with GRBL 1.1i for the MillRight MegaV.....

Sucks when you don't know what you're doing...

Best,
Kelly

[lloydsp]

Well, Kelly, if it's of any consolation, each of us was in the same situation you find yourself, when we fired-up our very first machine!  Ya' have to start somewhere!

Lloyd

[Tool-n-Around]

Well, Kelly, if it's of any consolation, each of us was in the same situation you find yourself, when we fired-up our very first machine!  Ya' have to start somewhere!

Lloyd

Thanks Lloyd. I do sincerely appreciate all the help. Just not use to being so helpless. At least I've experienced creating a cb file, corresponding Gcode, and watched the machine execute the intended tool path.......once Lol!

Best,
Kelly

[dave benson]

Hi Kelly

I'll try to be brief and describe the problem you have in a general way.
The manufacturer of your machine ships it with their own version of
GRBL a time locked in time 4th axis version.
That means that the firmware in the controller of your machine  is
not compliant with the standard GRBL and may require the post processor
to be modified.
The test I did where I ran the .NC file you posted worked ok on my test system
a 2560 mega running a fresh version of GRBL 5 axis connected to GRBLMachine.
and every simulator I had, I'm thinking the code 33 error (a controller firmware error code)
a little about the error code here https://discuss.inventables.com/t/12-0-002-grbl-arc-setting-question/30123/2
meaning that the motion translator in the controller can not find the next co-ordinates to go onto, in an arc.
The manufacturer may have changed this value ($12) from the default GRBL settings values 11 and 12
are shown in the pic or they may have been corrupted just check yours against the ones in the GRBLMachine pic.
Because this is a Millrite version of GRBL they may require a modified string format for the decimals.
so I've made this post processor for you, open the zip file and extract the file to my documents, then from there
copy the file to CB's post processor folder like in the pic.

Start CB and in the machining tab select GRBL1Mrite from the drop down list of post processors, draw rectangle
then apply a mop (profile outside) to it and generate the Gcode.

Now click on the GRBLMachine and go to the connection tab and press connect after selecting the usb com port
then  load up the .nc file you just made.

GRBLMachine will now ask if you want to use it's post processor or the one the CB file was generated with click no.
 run the file, It should run through with no errors. If it works (the post processor) can also be used with UGS

Hope that sorts you out.

Dave

[Tool-n-Around]

........so I've made this post processor for you, open the zip file and extract the file to my documents, then from there copy the file to CB's post processor folder like in the pic.

That was very generous of you Dave, and quite fruitful and beneficial to me. I incorporated a number of the other mods and suggestions by others in this thread, loaded and used your modified grbl post to create gcode files for this and 5 other files I have made and they all ran without any errors. Thanks so much to you and all the others who have posted the help to this thread. It was the most productive day of CNC accomplishment for me by a long shot. Watching them all run, I need to adjust some feed rates and cutting/toolpath redundancies, but barring the unforeseen, it appears they will all cut stock as intended. This spacer and it's lid do not require tool changes. The other four files do and have some features I need to add and have a couple questions on those and a few random questions related to this thread I'll post later.

......The manufacturer of your machine ships it with their own version of GRBL locked in time 4th axis version. That means that the firmware in the controller of your machine  is
not compliant with the standard GRBL and may require the post processor to be modified.

Wow. Is there any good reason for them to have done this? For now, your mod to the post processor appears to be working great. Just worried about the next thing I run into. In the long run would it be better to reflash to a known firmware or are these compatibility issues just common and I need to learn to deal with them? I feel like I have a little more wind in my sale after today.

I need to tram/square/calibrate, the machine. I also need to add some things for the dust shoe and vacuum line, but straight forward stuff that's easy to do.

Best,
Kelly

[Garyhlucas]

Kelly,
I've been thinking about tool changing without repeatable tool lengths.  I am still of the opinion that it will be easier if you make the table your Z height and set all your Z values as positive from there.  I used to own a CNC knee mill and to change from a short tool to a long one, like milling to drilling with a chuck I had to move the knee.  So setting the new tool off the table made it a lot easier.

I would write your programs out as separate files for each tool Manifold14endmill.nc, Manifold0156Drill.nc etc. Because you will need to set tool height every time and you won't be able to do that in context of an M6 tool change.  You can import an NC file that will get added right into the code that CamBam posts out to its NC file.  So create a little program that just moves your tool to the place you want to change it and set the Z length.  Call it ToolChange.nc.  Import this to the program where you want the tool change.  Your machine finishes the program above and moves to the tool change location and ends.  Change the tool, set the Z to zero on the table and run the next tool program.  I will tell you, forgetting to set the Z zero has crashed more tools on me over the years than anything else!

[Tool-n-Around]

Kelly, I've been thinking about tool changing without repeatable tool lengths.................

Thanks Gary. I understand and can see how to do what you describe....and special thanks to you for spending the time with me. Much appreciated!

Best,
Kelly

[Tool-n-Around]

A couple random questions arising from my experience of the last few days:

• If I set the machine origin at the top level of the machine tree, is it necessary to do so in each part or can the lower level setting remain as default NaN? If they are different, which one takes precedent?
• Is there a way to remove Machine Hold? When I get alarms, I can usually just use $X or one of the reset buttons to clear an alarm but I have to disconnect and sometimes reboot the controller to release a hold and regain the ability to issue commands.
• The touch pad on my lap top becomes slow and/or totally unresponsive when connected to the CNC controller. Oddly, if I pick the laptop up in my hand holding it the air, it operates normally but not while sitting on a surface 6ft away from the controller, whether the surface is conductive or not. I tried ferrite beads on the USB cable but no affect. Is it likely EMI or memory issue. Any ideas?

Best,
Kelly