reading external inx on Smartpin and setting c in setpat?
mwroberts
Posts: 97
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.
@mwroberts Can you please explain why you want interrupts on step pin events? Normally, CNC positioning applications have a loop with fixed cycle time (say 1ms) and just read the step counter once per iteration. If I understand what you actually need I could probably suggest how it can be implemented with smart pins.
About corner rounding: For CNC you normally want 90° corners sharp and low angle corners to be rounded. This is because trajectories that are no exact lines circles like bezier curves can only be aproximated by multiple small G1 segments. But you don't want the machine to stop and re-accelerate at each corner as this would be very jerky. To avoid acceleration peaks the corners have to be rounded which is usually done by low pass filtering X and Y positions sperately with a moving average filter.
Some data formats even can't represent circles at all (stl for example). And you don't want a ball look like a disco mirror.
@ManAtWork , I was trying to answer if GRBL overlaps prior move X steps with next move Y steps, without having a logic analyzer or storage scope. I have an arduino running GRBL and I send 8 or so moves to it quickly enough so it's buffer fills enough to do look ahead and junction velocity blending. The moves look like G91, Z10f500, Z10, Z10, Z10, Z10, Z10, X1, Y1 Instead of using interrupts I ended up doing a waitse1 on the first Y step, store clk count in var, followed by a waitse2 with that event set to watching X steps... count those and save the times... I only see one X step after Y steps start, and it is only 8 clocks after the Y steps start, at a sysclock of 200mhz... so I don't think GRBL overlaps prior X steps with next move Y steps. Bigger picture is I'm trying to understand what look ahead is... they talk about modifying the velocity profile in a forward pass through the buffered gcode, then a backward pass... The AI in cursor lets me pick it's brain on how GRBL works, getting insight I haven't been able to get prior... GRBL does a dot product on the velocity vector of the prior and next move to get the angle between them, and like you were saying, the closer the direction of the first velocity vector is to the next, the higher the junction velocity... the less you need to slow down between moves. GRBL does a lot of stuff on a 8 bit 16mhz arduino. I want to experiment with it's pulse generation technique... timer interrupt between steps on the axis with the highest step count for a specific gcode line, and bresenham to output the slower axis pulse on some of the higher rate axis pulses. I understand what you are saying about the moving average filter. You said that few years back and it took me a while to understand it... If you take a rectangular velocity profile and do a running average on it, you end up with a trapazoidal velocity profile, and if you do a running average on that, you end up with a s-curve velocity profile... you can do it in excel. Corner rounding depends on what the user wants, it is a tradeoff between speed and accurate path tracking.
Yes exactly. And you can do it with or without corner rounding. If you average the X and Y values seperately you get motion blending and rounded corners. If you calculate the 1D position on the linear trajectory, first, and do the filtering on that single coordinate only then you don't round the corners.
For a simple analysis of the GRBL step signals I'd do it that way but with two channels. Source code is included and very simple.