malcom2073

Forum Replies Created

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • in reply to: Issues with TinyG2 firmware on Arduino Due #7229
    malcom2073
    Member

    Win7, so no driver issues.

    I’m also connected to the native port, glad to hear you got it talking!

    I don’t have mine hooked up right now but next time I do I can let you know. I know I was seeing that before I got the DTR thing figured out…. not sure if it’s still doing it.

    in reply to: Issues with TinyG2 firmware on Arduino Due #7225
    malcom2073
    Member

    I’m using Windows, and that is correct I do not use Coolterm, I use a program I wrote.

    I see two com ports on windows, one called Data and one called Control. The Control one is the one I connect to, 115200 baud, and with CTS enabled it seems to be responsive. I actually trigger DTR line high, which causes the G2 to become responsive (where it was silent before)

    in reply to: Issues with TinyG2 firmware on Arduino Due #7223
    malcom2073
    Member

    Flow control defaults to XON/XOFF

    https://github.com/synthetos/g2/blob/edge/TinyG2/settings.h#L80

    However it seems that it’s actually supporting RTS/CTS control as opposed to XON/XOFF. I’ve not dug deeper to figure out why… some USB hardware drivers (as it’s using a composite device driver) don’t actually support hardware flow control… not sure if this one does or not but it seems that the define in that file has no actual effect.

    So if you want to communicate with it, make sure CTS is enabled, as per here: https://github.com/synthetos/TinyG/wiki/TinyG-Sending-Files-with-CoolTerm

    in reply to: Issues with TinyG2 firmware on Arduino Due #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.
    in reply to: Issues with TinyG2 firmware on Arduino Due #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!

    in reply to: Issues with TinyG2 firmware on Arduino Due #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!

    in reply to: Issues with TinyG2 firmware on Arduino Due #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.

    in reply to: Issues with TinyG2 firmware on Arduino Due #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.

    in reply to: Issues with TinyG2 firmware on Arduino Due #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.

    in reply to: Issues with TinyG2 firmware on Arduino Due #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.

Viewing 10 posts - 1 through 10 (of 10 total)