reading external inx on Smartpin and setting c in setpat?
mwroberts
Posts: 96
I've got a P_REG_UP_DOWN smartpin set up to count step/dir inputs from a GRBL board. I tried to get a setse1 interrupt for the step pin to work when the smartpin step input was set to P_LOCAL_A . Nothing worked untill I moved the step input up a pin and changed to P_PLUS1_A. This is probably because a smartpin output takes over the pin input, for signaling things like pwm overflow or timer count complete... I tried to get a setpat interrupt working on the local pin and that didn't work either, maybe it works now with the step input moved up 1 pin, but not sure how to set the "c" in the instruction?
In my latest sidetrack, I'm trying to figure out if GRBL does corner rounding. If you have a just X motion move, and the next move is a just Y motion move, does the Y move start before the X finishes? Cursor AI says no, google AI says yes... I'm working on writing timestamp data to the hub for X steps and Y steps with a dedicated cog interrupting on X steps, and another interrupting on Y steps...
Comments
You don't. The C and Z flags are independent so you have to prearrange them before the SETPAT instruction. There is various ways to set and clear the flags but the dedicated instruction is MODCZ, and its two aliases MODC and MODZ.
BTW: The four SETSEx events are easier.
Yes, IN become a smartpin controlled signal to the cogs. Normally you'd be wanting to see the smartpin status rather than its input pins.
The way that smartpin mode would use IN is by setting a sampling period with a WXPIN, making the smartpin a timer interrupt. Whereby the Interrupt Service Routine uses RDPIN to acquire the latest delta value of steps from the smartpin.
As for 2D, or 3D, motion control. The controllers specifically are designed for coordinated motion. Whereby any number of axis move in parallel according to the ideal calculated profile.
Thanks Evan... my investigation into GRBL behavior isn't related to a having x,y, and z move proportionally to each other in a block, ie gcode line, but more how it transitions from the prior moves velocity vector to the next moves velocity vector... they refer to it as look-ahead, and it will modify the prior moves decel and the next moves accel to so they meet at a "junction velocity" and they have another parameter called "junction deviation"... it does dot products to get the change in angle of the velocity vector... and if you modify the acc/dec, you need to make sure you don't change the the distance traveled ...
It is hard to believe, that this kind of speed up is used widely. Grbl is normally used for cnc, where you expect high precision. Let's say 0.01mm for a mill and a linear movement might often be 1mm or more. Additionally you often have acceleration and deceleration, so your gain in time is less than 1pc.
I have tried to use Bezier "edges" in my knitting machine. In this case sometimes allowed precision of edges is perhaps 1mm. But some movements have to be more precise.