chmr

Forum Replies Created

Viewing 15 posts - 16 through 30 (of 33 total)
  • Author
    Posts
  • in reply to: TinyG with Espruino (or other uC) #6799
    chmr
    Member

    Hi Eric,
    the ISP connector is only for flashing firmware and debugging with a special ISP adapter like the Atmel-ICE. You can’t use it to send Gcode commands to tinyg.

    However, on the tinyg V8 board you can use J14 to access the serial port that is also used by the USB connection. Connecting this to the Espruino should be straight-forward (very much like wiring up the bluetooth adapter to the Espruino). When the Espruino sends Gcode commands to the serial port, tinyg will execute them normally.

    Note that you can’t use tinyg’s USB and serial ports at the same time, as both of them use the same physical processor pins.

    in reply to: Footer Status Code 40 #6798
    chmr
    Member

    Hi,
    try {“gc”:”g28.2x0y0″}

    You seem to be using a rather old firmware version like 380.x, where tinyg.h contained:
    #define STAT_UNRECOGNIZED_COMMAND 40 // parser didn't recognize the command

    Recent versions respond with status 100, which is:
    #define STAT_UNRECOGNIZED_NAME 100 // parser didn't recognize the name

    I recommend using the newest version, especially for a developer.

    in reply to: TinyG need help urgently #6625
    chmr
    Member

    Hi, hard to tell what’s wrong from your description, but here are some suggestions:

    – Update the firmware for tinyg if you are running anything older than 435.10 ($fb). Also need to upgrade to the newest tgfx, and re-adjust the parameters.

    – Make sure flow control is set to RTS/CTS ($ex=2), also set this on the host program (I think tgfx does this automatically).

    – Check the mechanical side: Belt tensions, pulley set screws; for Z, make sure the threaded rod runs smooth on the whole range.

    – Motor setup: Adjust the motor current as described in the wiki, and try manual movement commands on every axis: G0Z20 should move Z axis up 20mm, G0Z0 move it back to the 0 position. “Plunging too far into the board” is often caused by wrong speed parameters: The z axis would move down with a slow feedrate, but when it should move up again, it can’t because the configured speed is set too high and the motor can’t follow. The next downward move will go into the wasteboard.
    First, set the speed settings to slow: $xvm=1000, $yvm=1000, $zvm=200, and same with acceleration (jerk) settings: $xjm=20, $yjm=20, $zjm=50. If the shapeoko runs fine with those, gradually increase the speed. I think the default shapeoko settings are a bit too optimistic.

    in reply to: Unable to set commands like $st=1 #6589
    chmr
    Member

    Hi, IIRC there was a bug in older firmware (412.x?) that displayed the $st value incorrectly. In other words, it used what you configured for $st, but when printing it, it always printed 0.
    This is fixed in the current firmware 435.10 (together with many other things), many good reasons to upgrade.

    in reply to: Easy question on measurement #6583
    chmr
    Member

    gagandeep,
    tinyg’s $xtr setting works differently than in grbl: In grbl, you configure (micro)steps per mm; tinyg wants mm per motor revolution. For the Ox, the thoretical value is 60 (60 teeth on the pulley * 3mm per tootn on belt). If you had $0=26.772 on grbl, on tinyg $1tr shoul be = 200 steps per revolution (1.8 deg motor) * 8 microsteps / 26.772 steps per mm = 59.764 mm per revolution. Seems pretty close to the theoretical value.

    contacttodd,
    calculation for your machine is the same: $1tr = number of teeth on pulley * distance of teeth on the belt. I just don’t know the actual values for your plotter.

    First amend the $Xsa (step angle, 1.8 for both) and $Xtr settings, then you can adjust the speed ($Xvm and $Xfr).

    in reply to: TinyG Connection Issues #6554
    chmr
    Member

    Hi Gwandad, I looked through your config and did not find anything unreasonable. I only noticed two minor things:

    The “travel per revolution” for X and Y axes is configured as 53.34mm. If the parts list of the Ox is up to date, it should be 60mm (belt has a tooth every 3 mm, and the pulley has 20 teeth; 3 x 20 = 60mm per turn). Might want to recheck this, but your measurement is definitely more reliable than (possible outdated) theoretical values.

    And I think it’s good that you lowered max velocity, you might want to do the same for acceleration/jerk ($xjm etc). 5000 million seems a bit high to me, my Shapeoko runs at (very conservative) 80 million. Better start low and later test the limits when you have confidence in the machine.

    I can’t really help on tgfx, as I don’t use it myself, but clicking on the bottom bar opens the console where you can type in commands and see the results.

    I wish you mucho fun with your Ox!

    in reply to: TinyG Connection Issues #6545
    chmr
    Member

    Gwandad, good to hear you have some progress.
    I’d like to clear up some confusion: Tinyg and GRBL are two different controllers offering the same functionality (with only a few differences). You have either tinyg or grbl, not both at the same time.

    Tinyg is a copntroller board + firmware.
    GRBL is a Arduino controller board + grblshield (motor driver) + firmware.

    “Universal Gcode sender” is not so universal after all, it only works with grbl, not with tinyg (speaking of the official version here, other people have ported it to tinyg).
    “GRBL controller” is a very misleading name for a software that sends Gcode to GRBL and only works with GRBL.

    To speak with Tinyg, you need other software:
    Tgfx, which you already have,
    Chilipeppr works within a browser window and has some nice features like a real preview of the Gcode,
    jCNC also works nicely with preview (german website).

    Coolterm is a very basic and simple tool, useful when you want to get directly to the tinyg hardware/firmware and want to exclude the influence of any other software. If it does not work, check the connection settings for baud rate and flow control (if tinyg is set to $ex=1, use XON in Coolterm; if $ex=2, use CTS in Coolterm).

    And you can only have one piece of software talking to tinyg at any one time, so you have to disconnect/terminate tgfx before connecting with Coolterm for example.

    in reply to: Testing Edge Builds 435.xx #6279
    chmr
    Member

    I was out of town this weekend, but tested it now when I came home: Both versions .07 and .08 fix the feedrate issues. No hasted circles, no clunking noises (I believe the clunk was when it tried to drive the motor too fast).

    Now for the tests that grath asked, with versions 435.06 and .08:

    Test 1
    (machine freshly reset and at 0/0/0)
    G0 X0.8 (06: X motor does not move; 08: X moves to X0.8)
    G0 X1 (06: X moves to physical X1; 08: X moves to X1)
    G0 X0 (06: X moves to physical X0; 08: X moves to X0).

    Test 2
    (machine freshly reset and at 0/0/0)
    G0 X0.8 (06: no move; 08: X moves to X0.8)
    G1 Z-1 F100 (06: Z axis moves ok, X axis moves to X0.8; 08: Z OK, X does not move)

    So with 435.08, all tests passed 🙂

    For completeness: My config is at https://www.dropbox.com/s/0k71o83yawv33lo/tinyg-config-20140629-43506.txt . My machine is a standard Shapeoko2 setup, only visible difference are 4x NEMA23 motors with 400 steps/rev.

    PS.: I test these things as low-level as possible with coolterm or putty; I don’t use tgfx.

    in reply to: A Bad Day in the Shop #6257
    chmr
    Member

    I think this was (part of) the fix for the clunking noises: If a movement is too short to execute in a controlled manner, don’t do it. I consider that OK as long as the physical position is remembered and the move is not forgotten (i.e. no drift between logical and physical position at the end of a cycle).
    But I agree that 0.8mm is a very high value, on my machine a full step is 0.12mm and a microstep 0.015mm . I have found no direct influence of max speed or jerk to that value, like it was before.

    I consider the other problems much more critical.

    in reply to: A Bad Day in the Shop #6255
    chmr
    Member

    Also this simple piece of gcode:

    G0 Z1
    G0 X0 Y50
    G1 Z-1 F100
    G2 X100 R50
    G2 X0 R50
    G0 Z3
    G0 X0 Y0

    Instead of feedrate 100, it tries to do it with a very high feedrate (I have seen speed 13k+ in the status reports). And the clunking sound is back.

    in reply to: A Bad Day in the Shop #6252
    chmr
    Member

    I tried the new firmware version 435.06, and at first it looked much better. When trying simple G0 moves like above, I found the following:

    (machine freshly reset and at 0/0/0)
    G0 X0.8 (X motor does not move at all, ? shows X=0.8)
    G0 X1 (X motor moves for 1mm, ? shows X=1.0)
    G0 X0 (X motor moves back to 0, so far OK).

    G0 X0.8 (motor does not move, like above)
    G1 Z-1 F100 (Z axis moves down, but X axis moves as well. Goodbye drill bit)
    (X is now physically and logically at 0.8)

    • This reply was modified 10 years, 5 months ago by chmr.
    • This reply was modified 10 years, 5 months ago by chmr. Reason: I hate this bbp forum software
    in reply to: Can't communicate with the TinyG since yesterday #6090
    chmr
    Member

    You can always try avrdude (instructions at https://github.com/synthetos/TinyG/wiki/TinyG-Updating-Firmware ), it just won’t help you. No flashing light == no bootloader.
    But you said you can see the TX light flickering, looks like the firmware is trying to send something out (the boot message).
    Let’s try the basics instead:

    1. unplug the tinyg USB cable, open the Windows device manager. Write down which devices are listed in the communication ports (COM and LPT) category.

    2. plug in tinyg USB and power. Do you hear the Windows-sound for new device connected? Look again in device manager, see if a new COM device is now listed (something like “USB serial device COM8”). If you don’t have a new device, check the USB cable, use a different USB port, check and/or update the FTDI device driver (see https://github.com/synthetos/TinyG/wiki/1.02-Connecting-TinyG).

    3. start CoolTerm, go to Options -> Serial Port. Make sure it is set to the COM port you found in step 2. Write down the old settings and change to baudrate=115200, data bits=8, parity=none, stop bits=1, flow control = nothing. Hit connect. If there is an error message, recheck step 2.

    4. press Enter a few times, try to enter “?” or $h a few times. If you get an answer, go to step 99. If you just get some garbled strings, the baudrate is probably incorrect (retry with different values).
    If you get no answer: Hold down the Enter key and look at the TX and RX Leds on the tinyg board. If they are flickering, there is basic communication. Try different baudrates. If none of them is flickering, recheck step 2.

    5. If you can’t get it to work, you will have to send it back to check/repair/update. Even without a working firmware, you should get some flickering on the RX Led.

    99. After you have communication:
    Enter $fb to get the firmware build.
    Enter $ex to see what kind of flow control is enabled in tinyg. Change the settings in CoolTerm to match that, and save your CoolTerm settings.
    You may want to return the board to Synthetos anyway so they can install the bootloader on it.

    I hope that helps.

    in reply to: Can't communicate with the TinyG since yesterday #6085
    chmr
    Member

    Hi,
    if the board is a bit older than a year, it may not have the bootloader installed (see https://github.com/synthetos/TinyG/wiki/TinyG-Boot-Loader for details).
    Am also interested in the answers to the questions in the previous post.

    in reply to: A Bad Day in the Shop #6061
    chmr
    Member

    My test “gcode” is that I typed in in the videos. It consists of “g0 x1” and “g0 x0.7” (might have to watch the videos in fullscreen mode, tinypic resizes it by default).

    in reply to: A Bad Day in the Shop #6058
    chmr
    Member

    And another short video, featuring the hammer-sound with $xvm=9600 $xjm=80. First, a moves to 1mm and back are done ok. Then, a move to 0.7mm and back produces the clunk.
    Video

    In this case, the actual travel was accurate. But this is not always the case, I have seen it also miss steps, or even jump in the wrong direction.

    • This reply was modified 10 years, 5 months ago by chmr.
Viewing 15 posts - 16 through 30 (of 33 total)