Forum Replies Created
-
AuthorPosts
-
alden
MemberAn arc specification error is a problem in the Gcode itself (unless there’s a bug in TinyG I’m not aware of, which happens). Can you please post the Gcode you are trying to run and where it fails? If it’s possible to cut the fie down to just the section that fails – that still reproduces the error – that’s even better.
Alden
MemberAaron. Please contact us at the synthetos gmail address. Sorry about your Y axis. Let’s get it replaced.
Alden
MemberLet me take a closer look at this. G38.1 probe cycles are on the list but not done yet.
For now you can navigate to your zero point and set a G92 offset to 0,0,0 (G92x0y0z0). It’s not automated, but it should work – although with less accuracy.
Alden
MemberThe ASCII code for control x (aka ctrl-x, ^x, CAN) is hexadecimal 18, 0x18. I don’t know how or if gcode sender sends this. You should read the documentation on grbl, as once you send a ctrl x there is an unlock you will need to do to get the system out of alarm mode.
Your other alternative is just to wire the reset button in parallel to some place more convenient to get at it. On the later versions of grblshield there is a 2 pin connector on the board you can solder in. In earlier version you need to attache directly to the switch.
MemberI think there is a command in grbl that you can send. It’s control x (^x) . Try that.
Alden
MemberJana,
Glad you got it fixed. The “single bounce” behavior you are now seeing is correct, and is different from the earlier code. This is deliberate. Here’s how it works now. (1) advance to the switch at search velocity and stop (decelerate) once the switch is hit. (2) back off the switch at a much lower latch velocity until the switch opens again. This is the set point. (3) back off the switch some amount to set the zero for that axis. My machinist friend told me this is the way it’s supposed to work, so I changed it.
In looking at you configs I see you using -400 for search velocity. The – sign is not necessary anymore as homing now always searches in the direction of the homing with – which it now knows because of the $xsn and $xsx settings.
Also, the latch backoff may be too small. I see you have just plungers and no leaf on the switch. If the latch backoff does not clear the switch the results will not be accurate, and the homing routine may not be able to clear a limit switch that was closed on initialization (i.e. you started homing but the other switch was closed). Try using 5mm – at least enough to back off a worst-case switch closed situation. With these types of switches you should also be careful not to search on them too fast as the axis needs to have enough room to decelerate without destroying the switch.
Alden
MemberHoming is very dependent on your settings. Can you list your $x settings and your $sys group? Are you using NO or NC switches and is $st set for the correct type?
The defaults are set up for X on the min switch. Have you changed the switch settings to reflect your setup with X on the max switch? I’d like to understand and reproduce your issue. Some pictures of your setup may also be helpful, as the backoffs need to be sufficient to clear the switches. This can vary widely for different switch arrangements.
MemberYou can find the tiny.hex file in the edge here: https://github.com/synthetos/TinyG/tree/edge/firmware/tinyg/default
The build in edge is 357.01 (not 537.01 as I typo’d) . You can see changes up to that point here: https://github.com/synthetos/TinyG/wiki/Road-to-1.0
Alden
MemberThanks for the kind words. I have actually done what you suggest, but the code is not in the Master release yet (on github). The way limits work 0.95 pre-release code in Edge is documented here – see the Limit Switch section.
https://github.com/synthetos/TinyG/wiki/TinyG-Homing
The Y and A have been fixed, and there is a software way to do a reset. However, it is up to the controller to restart the run – the board has no way to know where the tool actually is at that point. We have to assume that the machine has lost position when a limit is hit.
Please also note, the homing sequence has moved from G28.1 to G28.2 in order to make G28 compatible with the LinuxCNC (EMC2) behaviors.
Alden
MemberWe have considered this possibility. To that end we have been experimenting with pulse-width modulation (PWM) channels in the development / edge branches. There is more work to be done – for sure – but the basic of modulating laser are in place.
Alden
MemberThe grblShield is compatible with the current grbl releases from 0.7 onward with no patches. We work closely with the grbl project to ensure this is true. Thansk for pointing this out.
Alden
MemberTHey are all v4’s at thos point. Thanks for the catch. We need to update the site
December 18, 2012 at 5:47 am in reply to: Hacking the code: Wait for previous command to finish? #3663MemberI have anticipated a probe function and left stubs in the code to support a probe function this would be based on Gcode G38.2, which is the Gcode probe command. Here is what I would do if I were doing this:
— add a G38 command to the Gcode parser:
case 38:
switch (_point(value)) {
case 2: SET_MODAL (MODAL_GROUP_G0, next_action, NEXT_ACTION_STRAIGHT_PROBE);
default: status = TG_UNRECOGNIZED_COMMAND;
}
break;
}
…. case NEXT_ACTION_STRAIGHT_PROBE: { status = cm_probe_cycle_start(); break;}Add a file called cycle_probe.c modeled after cycle_homing.c. The homing logic can then be adapted to run a probe cycle. You will also need to go into gpio.c to configure any switches you are using, and to add a CYCLE_PROBE behavior to the ISR helper. CYCLE_PROBE is defined in canonical_machine.h, and would need to be set in cycle_probe.c when you enter the cycle.Of course there’s a lot more to it than this, but hopefully this will get you started.—AldenDecember 17, 2012 at 5:57 pm in reply to: Hacking the code: Wait for previous command to finish? #3661MemberIt might be good for us to integrate a vacuum controller in the code. I’m definitely interested.
December 17, 2012 at 3:16 pm in reply to: Hacking the code: Wait for previous command to finish? #3659MemberSimple. use cm_isbusy(). You can find an example in cycle_homing.c
uint8_t cm_homing_callback(void)
{
if (cm.cycle_state != CYCLE_HOMING) { return (TG_NOOP);} // exit if not in a homing cycle
if (cm_isbusy() == true) { return (TG_EAGAIN);}// sync to planner move ends
return (hm.func(hm.axis));// execute the current homing move
}
Can I ask what you are trying to do? It might be something we should include. Also, I’d work from the edge branch if you are going to hack anything. Be aware that it will be updated a few times in the coming weeks–Alden -
AuthorPosts
