Overshooting Max Velocity

Home Forums TinyG TinyG Support Overshooting Max Velocity

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • #5341
    RodeoClown
    Member

    My TinyG started playing up tonight, it is ignoring the maximum velocity settings and shooting up to 8000 when the axis needs to travel a large distance.

    I have turned $yvm $yfr and $ysv all the way down to 100 to troubleshoot it, and am still seeing it shoot up to 8000.

    Is there a setting anywhere that could be overriding this, I went through the gcode and there is nothing that is off. It does it on the first movement line which is G0 X-43.992 Y224.789.

    Should I reflash?

    #5342
    alden
    Member

    This is a new one on us.

    One thing to be aware of is the maximum velocity sets is used by traverse (G0, $_vm) and it reacts differently than a feed (G1, $_fr). A traverse is designed to go as fast as possible for point A to point B. The $_vm sets the maximum velocity *for that axis*, not for the traverse move. In a multi-axis traverse the resulting movement can therefore be faster than any individual axis in the move. For example, if you moved from (x0,y0) to (x100,y100) and had both xvm and yvm set to 1000, the move velocity would be 1414. Neither axis exceeds it’s limit of 1000 (1414 is just the vector sum of the velocities, i.e. 1000 * sqrt(2))

    This is as opposed to feeds (G1), which limit the total rate of the move to the F rate specified in the move (e.g. G1 F1000 x100 y100). Alternately, a feed may be limited by the max feed rate for a given axis, and the total feed rate of the move therefore reduced.

    So if your move had a minimal Y movement and a long X movement it’s still possible that the move itself will achieve a speed well above the Y limit. This may or not be the situation in your case.

    If you think there’s some other problem can you let us know a few things:

    – What firmware build you are running? – e.g. $fb 380.08

    – What are your X and Y settings (assuming only X and Y are in the move), $x, $y

    – What is the starting point of the move? Assuming the end point is X-43.992 Y224.789.

    – Just for completeness, what kind of machine are you running? Sounds like a belt driven machine given the high velocities you are using

    #5353
    RodeoClown
    Member

    So I upgraded my firmware last night to the edge release 412.01 to see if it helped but it didn’t. However that build takes away the ability for me to have NC limit switches so I had to do a quick require.

    I have figured out what was causing the issue I think. I am using Autodesk Inventor with the free HSM Express CAM add-on which is brilliant. But it creates G-Code that is rather verbose which TinyG just ignores, at least I thought it did.

    It turns out removing the following from the G-Code stopped the issue happening. I have googled each line and can’t figure out why though.

    (T1 D=3. CR=0. – ZMIN=-2. – FLAT END MILL)
    G0 G90 G94 G17
    G21
    G53 Z0.

    (2D CONTOUR1)
    M5
    M9
    T1
    S5000 M3
    G54
    M8

    The other thing I did was to change the first line from G0 to G1 and specified a FR, but that didn’t help on its own.

    Machine is self built, 500mm x 500mm working area driven by ballscrews with 5mm of movement per rotation, which is why the 8000 velocity is waaaaaay too much, and my steppers just stop. Oh and I am zeroing x and y before doing this move. I’ve managed to get the accuracy down to .01mm with most things I make being pretty much spot on (My calipers and digital angle measurers only go to .00mm/degrees so I don’t actually know how close to perfect I am). So far, I am pretty impressed with the Inventor and TinyG combo, it is an amazingly fast way to get great results.

    #5354
    alden
    Member

    Interesting.

    Can you explain what you mean by “takes away the ability for me to have NC limit switches”? As far as I know nothing has changed in that area and the $st (switch type) parameter is still present and active. If you found otherwise we should fix this.

    Thanks for the list of commands you removed from the Gcode file. To my knowledge none of these should prevent the file form running, but there may be a bug. I’ll try them out and see if there’s a problem somewhere.

    Is it possible to provide a link to the Gcode file you ran, or short of that posting the first 100 lines or so? I’d like to run this in context if possible.

    If your machine won;t do 8000 mm/min you should probably drop the velocity maxes down to what each axis can actually handle. That should prevent the stalling. You may also need to adjust your jerk values. See here for some tuning guidance: https://github.com/synthetos/TinyG/wiki/TinyG-Tuning

    #5355
    mcgyvr
    Member

    Did you use the tinyg post included with hsmexpress..?
    I’m going to be using Inventor and hsmxpress very shortly on my new personal DIY machine.
    I’ve been using Inventor/HSM with a Haas VF2 and its worked flawlessly so far.

    #5362
    RodeoClown
    Member

    Yeah, was quite surprised to see it in the list when I first did it. But there it was and it works quite well.

    As far as the Switch type goes, I send $st 1 and it responds with $st 0. If I go to tgfx and query it, the switch is NO. I just rewired my switches to NO as a workaround, but I would like to go back to NC as I feel safer.

    Also, just to reiterate; My machine isn’t set to 8000 mm/min it is set to 600. It just was ignoring the 600 setting and trying to get to 8000.

    #5391
    Riley
    Keymaster

    RodeoClown, let me verify this. This might be a bug in tgFX.

    ril3y

    #5392
    RodeoClown
    Member

    I did it through terminal and got the same results, but now a couple of days later it has switched and is now on $st 1 but won’t switch to $st 0… it isn’t that big of a deal. The big issue I have is when I hit the limit switch it throws the message through terminal and on tgfx as well, but the machine keeps moving, it doesn’t stop until I reset it(panic button).

    Where can I find the latest non edge firmware so I can roll back?

    #5393
    alden
    Member

    There’s a new download page with master and edge here:

    http://synthetos.github.io/

    We’ve opened a bug on your limit switch misbehaving in edge. I won’t be able to test this for a few days as I’m traveling.

    #5395
    RodeoClown
    Member

    Thanks, I just ate a chunk out of one of my clamps as I was a couple of meters from the panic button. Turns out I can cut steel without much effort. 🙂

    I will roll back now.

Viewing 10 posts - 1 through 10 (of 10 total)
  • You must be logged in to reply to this topic.