Issues with TinyG2 firmware on Arduino Due

Home › Forums › TinyG › TinyG Support › Issues with TinyG2 firmware on Arduino Due

Viewing 15 posts - 1 through 15 (of 24 total)
1 2
  • Author
    Posts
  • December 18, 2014 at 9:52 pm #7197
    malcom2073
    Member

    Hiya! I’m running G2 on an Arduino Due, attached to a Gecko G540 stepper driver on a ballscrew driven 3d printer.

    [fb]  firmware build             37.03
[fv]  firmware version            0.80
[hp]  hardware platform           3.00
[hv]  hardware version            0.00

    I got this firmware from the github downloads page. I’m currently running my own gcode sending application since I couldn’t get tgFX to connect.

    When I run this chunk of gcode:

    G1 X49.312 Y40.709 F4200.000
G1 X50.630 Y40.777 
G1 X51.260 Y40.832 
G1 X52.626 Y41.050 
G1 X54.320 Y41.817 
G1 X55.530 Y42.489
G1 X56.858 Y43.788
G1 X57.765 Y44.834
G1 X58.572 Y46.516
G1 X58.699 Y46.827
G1 X58.989 Y47.750
G1 X59.035 Y47.746
G1 X59.189 Y49.014
G1 X59.247 Y49.659
G1 X59.259 Y49.994

    I get an error:

    ALINE() line0 0.000011
tinyg [mm] err: Move less than minimum time: G1 X59.035 Y47.746 
posx:53.071,posy:44.088,vel:3487.864,stat:5
posx:49.487,posy:40.649,vel:338.393
posx:55.670,posy:42.493,vel:1295.647
posx:59.043,posy:47.639,vel:245.400
posx:59.035,posy:47.746,vel:0.000,stat:3

    What does this mean, and is it safe to ignore? I assume this means that the move time is so tiny, that it makes no sense to make this move, so I should just continue on with the next line and ignore it?

    I also get periodic “######## LOADER – SEGMENT NOT READY” messages, what do these mean?

    December 18, 2014 at 10:45 pm #7198
    malcom2073
    Member

    So it looks like the “######## LOADER – SEGMENT NOT READY” can come in a bad place, in the middle of other messages such as “pos######## LOADER – SEGMENT NOT READYx:42.125,posy:24.183,vel:1280.253” or “tinyg [mm] ok######## LOADER – SEGMENT NOT READY>”, I should probably figure out what’s causing that and stop it from doing so, since it makes it difficult to parse responses.

    December 19, 2014 at 6:38 am #7199
    cmcgrath5035
    Moderator

    There are very few lurkers here from G2 space. You might want to try adding an issue at

    The developers spend more time in that space than here.

    I have no hands on experience yet, but wonder if you reduce your speed (from F4200), does that affect the error message occurrences?
    Might the (computed move)/(Fspeed) be less than the time between microstep intervals?

    December 20, 2014 at 5:44 am #7204
    malcom2073
    Member

    I cross posted on the G2 issue list, but yeah reducing the speed below a certain point makes the Move Less than minimum time message less likely to happen, but that defeats the purpose of using TinyG, and that is the motion control system allows my system to move way faster than the alternatives without skipping steps.

    December 20, 2014 at 7:01 am #7205
    cmcgrath5035
    Moderator

    I understand your comment “… defeats the purpose…”.
    It will likely be helpful to the developers to have a full $$ parameter dump to look at. Posting it using the the method here

    makes them easier to review.

    From your description, I envision that you are developing your own ‘intelligent’ GCode sender that is actively monitoring the return messages?

    My next suggestion would be to leave your speed high but experiment with the Jerk settings on X and Y. It seems that establishing optimal Jerk values is a combination of engineering and art, and vary from machine to machine.
    Have you computed the stepper RPM required to move at your chosen F values? Seems they must be rather high, although I have no set up experience (travel per revolution, etc, parameters).

    December 20, 2014 at 8:25 am #7206
    malcom2073
    Member

    As I don’t have a dropbox account, I pastebin’ed my $$ output: http://pastebin.com/vB7tywz6

    I can upload any files needed to my website and link here if required.

    I’m only looking at X and Y right now, Z is not hooked up.

    You are correct that I have my own intelligent GCode sender, and I’ve not eliminated that as the issue as it is possible that I’m sending things wrong: I’m waiting for “ok>” message, and then sending… is this proper? I’m assuming it works like other buffered gcode devices… but that’s an assumption based on no fact whatsoever 🙂

    One thing of note, my driver is a Gecko G540, which is hard-set to 1/10 microstepping. I have a ballscrew of 8mm per revolution, so putting a value of 6.4mm and 8 microstepping in TinyG makes it move the proper distance since 10 isn’t an option for microstepping.

    I fiddled with the jerk value and seemed to find that 1 billion is a decent setting for not skipping any steps, do you mean to try lowering that to reduce the number of error messages?

    To move 4200 requires a stepper rpm of 525. This is well within the capabilities of the actuators I’m using. They’re rated by the mfg to be good up to 200mm/sec, or 1500rpm… though I’ve no intention of running them near that speed.

    December 21, 2014 at 7:09 am #7207
    cmcgrath5035
    Moderator

    Can we assume you have reviewed this wiki item

    relative to buffering and Gcode delivery? While authored for tinyG running on ‘older’, lower performance hardware, I believe the intention of the port to G2 is to maintain a common approach.
    And there is the G2 wiki as well

    While I have not implemented what you are doing, my read is that maintaining optimal planning buffer fill is achieved by streaming the Gcode to tinyG under flow management by the serial I/O. For original tinyG, that was set by $ex to Xon/Xoff or RTS/CTS, for G2 of course it is native USB.
    More aggressive buffer management is implemented by the Chilipeppr folks using the queue report mechanism.

    Waiting for “ok>” seems as if you are implementing a ‘robot’ that types in a GCode command, waits for it to complete, then send the next command , but to use your comment, “that’s an assumption based on no fact whatsoever :)”. It would appear that this manner defeats the concept of a planning buffer and the third order curve fitting/planning strategy. But I am way beyond reasonable assumption boundary here.

    Your approach to ‘spoofing’ timyG to match up with your fixed 1/10 microstepping seems reasonable.

    December 21, 2014 at 7:12 pm #7208
    malcom2073
    Member

    Ah nope, I had missed those wikipedia articles, you all do buffer management differently than the other controllers I’ve interfaced with (see standard reprap, where “OK>” means there is space in the buffer, not that the command has completed), I will modify my code to do queue reports and see if that helps.

    December 22, 2014 at 10:01 am #7209
    cmcgrath5035
    Moderator

    As I am sure you have already figured out, those are references into the Synthetos Wiki, not wikipedia.
    If you start here

    You’ll see tinyG, G2 and tgFX, code as well as wiki references.

    I suggest you study Chilipeppr as well,

    Chillipeppr is a ‘third party’ development but closely coordinated with the tinyG folks. Lots of hints on their forum on the nuisances of buffer management and flow control

    December 22, 2014 at 12:40 pm #7210
    malcom2073
    Member

    As I am sure you have already figured out, those are references into the Synthetos Wiki, not wikipedia

    Yep. mis-type on my part.

    Turns out I’m also running really old firmware (no binaries available for newer it seems), so as soon as I can get more recent firmware to compile I’ll try that in addition to the queue report stuff.

    I’ll move any more discussions on this over to the G2 issue list, thanks for your help!

    December 22, 2014 at 6:24 pm #7211
    cmcgrath5035
    Moderator

    I have not compiled G2 in a while – what version compiled for you?
    You are running Edge, correct?
    I am in need of updating myself.
    What host OS do you compile/download from?

    December 24, 2014 at 2:37 pm #7218
    malcom2073
    Member

    I got edge up and running, got it compiling on latest Xubuntu.

    It seems to have solved a lot of the issues, and using queue reports solved the rest, so I believe I’m up and running now. thanks!

    December 24, 2014 at 5:13 pm #7219
    cmcgrath5035
    Moderator

    What did you use to generate your $$ report (pastebin above)?
    I can’t seem to interact with the Host USB port after flashing (via the Programming port). The RX light is slowly flashing, waiting for me to connect..

    Good news on your end!

    December 25, 2014 at 5:39 am #7220
    malcom2073
    Member

    I couldn’t get tgFX to work, or even cutecom/putty… so I wrote my own gcode sender/interface application and I have a button to generate the report by sending “$$” to the board.

    Something of interest, the new firmware requires the CTS line to be pulled either low or high… I don’t have the code in front of me to check, but without that it would not respond. I’ll check tonight when I get home and let you know.

    • This reply was modified 9 years, 10 months ago by malcom2073.
    December 25, 2014 at 6:37 am #7222
    cmcgrath5035
    Moderator

    Thanks. CTS? I’ll hack about a bit.

  • Author
    Posts
Viewing 15 posts - 1 through 15 (of 24 total)
1 2
  • You must be logged in to reply to this topic.