|
|
Post by breslinmr on Jul 27, 2017 23:11:45 GMT
 It wont even make it to homing switches and this comes up on screen. There must be a simple setting. I have checked wiring and there is power to switches so they look good. Any help greatfully apreciated |
|
|
|
Post by Derek the Admin on Jul 28, 2017 1:46:13 GMT
This is pretty embarrassing, but I've recognized a bug in our firmware settings that are making you fail. I apologize for this inconvenience.
Settings 130, 131, and 132 are wrong. We left those at default settings in the firmware we've been flashing and somehow didn't catch it.
Change the settings as such:
$130=440
$131=440
$132=95
Type each one of those into the commands line and press enter one at a time.
Basically, what was happening is that it was expecting to travel 200mm and when it started to travel a certain distance beyond that it just stopped and said "Whoa, we've gone to far!"! Apologies for that.
You can check your status of the switches by turning on verbose output. In UGS Platform, go to Tools (at the top) menu bar/Options/ UGS tab (at the top of the window that pops up)/Console .... then click "show verbose messages". Then click ok. I'll have to check at the office tomorrow if the status reporting bits will display switch status and get back to you on that. You might be good to go after you change settings 130 - 132 that we botched.
Also, for what it's worth, you can run it without the homing switches by zeroing your position with G92 X0 Y0 Z0... that would designate the current position as the work origin. The homing will be useful when you want to create a work coordinate origin that you want to come back to on a regular basis.
|
|
|
|
Post by breslinmr on Jul 28, 2017 2:44:11 GMT
This is pretty embarrassing, but I've recognized a bug in our firmware settings that are making you fail. I apologize for this inconvenience. Settings 130, 131, and 132 are wrong. We left those at default settings in the firmware we've been flashing and somehow didn't catch it. Change the settings as such: $130=440 $131=440 $132=95 Type each one of those into the commands line and press enter one at a time. Basically, what was happening is that it was expecting to travel 200mm and when it started to travel a certain distance beyond that it just stopped and said "Whoa, we've gone to far!"! Apologies for that. You can check your status of the switches by turning on verbose output. In UGS Platform, go to Tools (at the top) menu bar/Options/ UGS tab (at the top of the window that pops up)/Console .... then click "show verbose messages". Then click ok. I'll have to check at the office tomorrow if the status reporting bits will display switch status and get back to you on that. You might be good to go after you change settings 130 - 132 that we botched. Also, for what it's worth, you can run it without the homing switches by zeroing your position with G92 X0 Y0 Z0... that would designate the current position as the work origin. The homing will be useful when you want to create a work coordinate origin that you want to come back to on a regular basis. Thanks for the info Derek I changed the three setting as you said and it goes past switches still and does the grinding noises. I done the verbose thing and it's doing some kind off scan on the console it says (Verbose)<Idle|MPos:-2.000,19.000,0,000|F:0|Pn:XY|WCO:-434.800,-280.400,-83.400> <Idle|MPos:-2.000,19.000,0,000|F:0|Pn:XY|Ov:100,100,100> Don't know if that makes any sense to you lol it doesn't to me |
|
|
|
Post by Derek the Admin on Jul 28, 2017 12:40:08 GMT
Okay. I'll get back to this later today and walk you through how to interpret status reports so we can get these switches diagnosed. Bare with it, I guarantee we will work this out.
|
|
|
|
Post by Derek the Admin on Jul 28, 2017 18:33:47 GMT
Okay, I'm back on this. Once you enable verbose output you'll get reports on all the different statuses streaming to the screen. If you physically activate a switch by pressing it with your hand, it should say "Pn:X" or "Pn:Y" or "Pn:Z" at the end of that status text. Let's do that and see if you have the status indicated. If not, we'll take it from the ground level on switch troubleshooting. Here's an example of me activating the X switch by hand with verbose output enabled:  Derek |
|
|
|
Post by breslinmr on Jul 28, 2017 21:43:04 GMT
Okay, I'm back on this. Once you enable verbose output you'll get reports on all the different statuses streaming to the screen. If you physically activate a switch by pressing it with your hand, it should say "Pn:X" or "Pn:Y" or "Pn:Z" at the end of that status text. Let's do that and see if you have the status indicated. If not, we'll take it from the ground level on switch troubleshooting. Here's an example of me activating the X switch by hand with verbose output enabled: Derek Ok well I've em well you know I'm only new at this 😔😔and I only recently well em ah shit long story short I got my X and Z mixed up on the board. It now homes 😩😩 go on say it nothing I haven't said to myself lol sorry. Bleep bleep Having other problems at minute lol. But don't want to say I case make more off an idiot off myself. But curious if I uninstall Goode platform and reinstall it. Wouldn't do any harm would it think I might have messed my settings up but not sure lol |
|
|
|
Post by breslinmr on Jul 28, 2017 22:10:15 GMT
|
|
|
|
Post by Derek the Admin on Jul 29, 2017 0:40:44 GMT
Glad the homing is good now. The error code you are getting in UGS most likely means that there is something in the g code that is unacceptable. G Code is a standard, but it's a loose standard. It could be, for instance, specifying an arc in a way that is unacceptable to grbl's g code processor.
What file are you sending it? How did you generate the file? Can you give me a copy to examine?
I have also seen something similar when someone somehow got a weird code into their start-up block, which is a few lines of code that run everytime the controller boots up. Does it throw this error on start-up, on loading a file, ot on running a file?
|
|
|
|
Post by breslinmr on Jul 29, 2017 1:54:31 GMT
Glad the homing is good now. The error code you are getting in UGS most likely means that there is something in the g code that is unacceptable. G Code is a standard, but it's a loose standard. It could be, for instance, specifying an arc in a way that is unacceptable to grbl's g code processor. What file are you sending it? How did you generate the file? Can you give me a copy to examine? I have also seen something similar when someone somehow got a weird code into their start-up block, which is a few lines of code that run everytime the controller boots up. Does it throw this error on start-up, on loading a file, ot on running a file? not at the computer at the minute but I done one cut and almost came out perfect had my feed rate too high but it still cut with no prob. Now it will cut half a letter and stop dead in its tracks and error code comes up. Had another mishap were the router wend south and fast lol through my spoil board and bed of machine but almost 100% that was operating error 😳 and as forest gump would say and that's all I have to say about that i was using aspire was just a little text and just saved it as g code file as I did the other one |
|
|
|
Post by Derek the Admin on Jul 29, 2017 3:28:01 GMT
What post processor are you selecting in aspire? It's just coming across a code that grbl won't accept. We just need to get you steered over to the right post-processor. Think of post processors like adapting a language to a particular dialect. The language is G code, and each controller has it's own dialect. It's like if you were to tell an American guy to open the bonnet of the car. He will stop and say, open what? The British guy will go open the hood.
Post the G Code when you get a chance and take a screen shot of your post processor options and we will walk you into target. Usually a mach3 post will also work.
|
|
|
|
Post by breslinmr on Jul 29, 2017 17:08:31 GMT
What post processor are you selecting in aspire? It's just coming across a code that grbl won't accept. We just need to get you steered over to the right post-processor. Think of post processors like adapting a language to a particular dialect. The language is G code, and each controller has it's own dialect. It's like if you were to tell an American guy to open the bonnet of the car. He will stop and say, open what? The British guy will go open the hood. lol Post the G Code when you get a chance and take a screen shot of your post processor options and we will walk you into target. Usually a mach3 post will also work. So im back not sure how to send g code, attached image of post processors there are loads of them so have attached what i thought.  |
|
|
|
Post by breslinmr on Jul 29, 2017 17:12:17 GMT
|
|
|
|
Post by aforww on Jul 29, 2017 20:09:57 GMT
That would be the correct one.
|
|
|
|
Post by breslinmr on Jul 30, 2017 3:51:15 GMT
That would be the correct one. Sorry was away all day before I left I tried a dust shoe template and worked perfect must have been using wrong processor. Thanks for all help much appreciated |
|
|
|
Post by aforww on Jul 30, 2017 4:20:01 GMT
Not a problem
|
|
