cmcgrath5035

Forum Replies Created

Viewing 15 posts - 1,636 through 1,650 (of 1,771 total)
1 2 3 … 109 110 111 … 117 118 119
  • Author
    Posts
  • June 6, 2014 at 4:55 pm in reply to: Can't communicate with the TinyG since yesterday #6088
    cmcgrath5035
    Moderator

    The picture you posted is a V7, that is what mine is. Mine did not have a boot loader installed either; boot loaders became standard at the very end of V7 shipments and into V8’s.

    1-2 seconds is too fast for boot loader, so it is probably just booting.

    I recall reading somewhere about induced voltages from steppers affecting some hardware, not sure that was tinyG. But someting may have scrambled parameters resulting in your communications issue.

    To get a boot loader installed you either need an Atmel programmer(see wiki) or return it to Synthetos for a brain transplant

    June 6, 2014 at 12:52 pm in reply to: Can't communicate with the TinyG since yesterday #6084
    cmcgrath5035
    Moderator

    OK, I am a bit confused, so a bunch of questions.

    First – on a working tinyG, on powerup or hit-reset-button, you should see Spindle CW/CCW LED flash for 5-7 seconds, then Spindle pwm LED on solid.
    The flashing is while in bootloader/boot process.

    Something does not sound right with your unit.

    Have you ever run a FW update?
    If so, how? avrdude? other?
    Is your HW ver 7 or ver 8? (Silk Screen on PWB)
    Is the TX that is on near the USB connector?
    I have a blue LED on there, can’t read the SilkScreen.

    Above, you say you tried update, but nothing happened.
    Was that via tgFX?
    If tgFX can’t connect, it can’t manage a FW update either.

    June 6, 2014 at 9:32 am in reply to: Can't communicate with the TinyG since yesterday #6081
    cmcgrath5035
    Moderator

    Have you always just used Coolterm to communicate?

    If purchased a year ago, FW is rather old. If you connected via tgFX, it may have initiated a FW update, that did not complete properly.

    What OS on your PC, Windows?

    1 to 2 seconds sems a bit quick for a full Boot cycle.

    Have your tried issuing a $[CR] or $$[CR] after pressing reset?

    June 3, 2014 at 7:38 pm in reply to: Does Tiny G replace Serial Ports? #6074
    cmcgrath5035
    Moderator

    I have never looked hard myself, but have read discussions of others that leads me to believe you have to pick off the inputs to the on-board drivers and extend them / interface them to your externals.
    I do not believe it is as easy as connecting the tinyG outputs (motor winding switches) to your external drivers.

    This post in in the tinyG sub forum.
    Back up to the “Forum” level, then enter External Stepper Drivers in the Search box. You see several posts on the topic.

    June 3, 2014 at 1:29 pm in reply to: Does Tiny G replace Serial Ports? #6072
    cmcgrath5035
    Moderator

    Simple answer : yes

    More complex answer – as I understand it, with parallel port to stepper interfaces, the parallel port lines connect to stepper drivers, essentially a hardware interface function.
    tinyG interprets Gcode, does acceleration and movement planning and interfaces directly with steppers. So tinyG does some of the intelligent work done by PCs driving parallel ports.

    tinyG implements third order motion planning.
    A similar product, Gshield and GRBL, FW running on Arduino Uno, performs similar tasks, but using second order motion planning.

    Both interface to computer via USB.

    Both are probably equally challenging to interface to external drivers.

    HTH

    June 3, 2014 at 11:46 am in reply to: Does Tiny G replace Serial Ports? #6068
    cmcgrath5035
    Moderator

    I am sort of new to build-it-yourself CNC, so am not sure what you frame of reference might be.
    TinyG is a Gcode to Stepper motor interface, correct.
    It connects to a hose computer, via USB.
    Machine and GCode parameter configuration is stored in tniyG, but Gcode must be streamed to the tinyG.
    Some folks have interfaced tinyG to external drivers; search the forum and Wiki.
    When I first entered this activity, the primary options seemed to be Parallel Port interfaces (e.g. LinuxCNC) and USB. I am not familiar with any serial solutions, but as said, sort of new.

    June 2, 2014 at 11:15 pm in reply to: A Bad Day in the Shop #6065
    cmcgrath5035
    Moderator

    Final update on this topic, I hope.
    With build 429.01 loaded, I dialed back xvm and yvm to 1000 (from 16000), experienced no “clunking” and got a clean production run. Since the bulk of the job is G1 machining, already run at F200, not a significant increase in overall job execution time.

    June 2, 2014 at 8:28 am in reply to: A Bad Day in the Shop #6062
    cmcgrath5035
    Moderator

    Ah, gotcha. Yes, the CoolTerm widow is tough to see, plus it was more fun to watch the microscope :).

    But you answer my real question – you induced failures with short X-Y moves, not short arcs, but (relatively) high max velocity.
    I guess that might explain why the tough test cases flux and dataway provided ran OK, as the short moves were at G1 velocity, not G0.

    That also explains why some of my engraving short arcs are OK (no knocks) as they are continuous arc to arc, no G0 moves.
    It is the “Illogical Gcode” hopping around (at G0) that reveals this.

    I’ll retry this Job with 429.04 with the $xvm and $yvm set much lower.

    Thanks

    June 2, 2014 at 6:26 am in reply to: A Bad Day in the Shop #6060
    cmcgrath5035
    Moderator

    Thanks, Chris, for the confirmation and detailed analysis.

    Could you perhaps make you test Gcode available (e.g. post a link)?
    It might be easier to work with or more revealing to Alden than mine.

    June 1, 2014 at 11:28 am in reply to: A Bad Day in the Shop #6054
    cmcgrath5035
    Moderator

    Update – not quite so bad a day

    Rather than count sheep last night, I mulled the days activities.

    One item that bothered me a bit was that when I was shutting down my laptop, which I normally do via Suspend to RAM, it crashed.
    I had encountered some issues between tgFX builds 3259 and 3256 and tinyG during my session, and I am aware of other reported memory issues that Riley is currently chasing.

    I just tried once again to load tinyG build 429.01 using avrdude after a full reboot of the laptop. When I powered on tinyG, it was already in fast-flash mode, presumably in boot loader.
    I issued the avrdude command for installing, and the install completed first try. Verified by starting a tgFX-tinyG session.

    The good news – no reload of boot loader required.

    I still believe there is an issue with tinyG builds 429.01 and 429.04 processing the short arcs Gcode posted above.

    • This reply was modified 10 years, 8 months ago by cmcgrath5035.
    May 30, 2014 at 8:09 pm in reply to: 429.04 motor power management #6050
    cmcgrath5035
    Moderator

    Chris
    I observed the same behavior with tinyG builds 429.04 and 429.01.
    I did not diagnose to your level of detail – seems we already have good data for Alden to work with.

    May 30, 2014 at 7:56 pm in reply to: Tests with Updated tinyG and tgFX versions – Linux Environment #6048
    cmcgrath5035
    Moderator

    I am encouraged to report some success and hopefully the final entry in this thread.
    My tinyG is now running FW build 429.04. I reran my Gcode files using tgFX build 3259.
    Results
    test

    It appears to me that the error resulting motion overshooting the “best’ available x,y by 0.0228mm (the resolution of my ShapeOko setup) has been eliminated.
    If interested, scroll back in this thread to see the original error.
    I first observed this error in the ShapeOko test pattern shown here
    test

    On to bigger and better challenges

    • This reply was modified 10 years, 8 months ago by cmcgrath5035.
    May 30, 2014 at 3:56 pm in reply to: Electronics Shopping List Approval Needed #6038
    cmcgrath5035
    Moderator

    Spindle; I don’t think my machine is in your league, but find the DW660(my spindle) to be a relatively large mass for the X Servo to control. It also puts a good twist load on the axis member, but you seem to have that covered. If you had an even larger router, controlling/moving that mass could be a challenge, mitigated of course by the torque gain inherent in the screw based design.

    Stepper power – that will depend a lot on your stepper to lead screw ratio, or do the steppers directly drive them? And, obviously, the efficiency of / drag on the screws from the movable elements.

    Thermal – actually, I was worried more about tinyG thermal management.

    May 30, 2014 at 3:41 pm in reply to: Nema 23 motors won't spin just make noise, help please. #6036
    cmcgrath5035
    Moderator

    Assuming it is a single pole eStop button, then it wants to be in series with the live (24V, probably) wire.
    I suppose you might have a double pole switch, but no need to open the return (negative).

    May 30, 2014 at 2:38 pm in reply to: Nema 23 motors won't spin just make noise, help please. #6034
    cmcgrath5035
    Moderator

    Good points, Chris.
    A quick look at shapeoko 2 – dual Y.config finds it setting up 1.8 degree step angles, since most ShapeOko s are NEMA 17s, until customized.
    I suspect your travel per rotation might need a tweak as well; that depens on the pully and belt system you are using.
    Also, the default G0 speed is set to 16000, which is fast but OK, but the default G1 (machining) speed is also 16000 which is fast for cutting anything but air.
    Normally, the GCode would slow the G1 speed significantly.

  • Author
    Posts
Viewing 15 posts - 1,636 through 1,650 (of 1,771 total)
1 2 3 … 109 110 111 … 117 118 119