cmcgrath5035

Forum Replies Created

Viewing 15 posts - 61 through 75 (of 1,771 total)
  • Author
    Posts
  • in reply to: TinyG Machine Status idle with Universal Gcode Sender #12020
    cmcgrath5035
    Moderator

    I am still not sure I understand what you mean by “stopped tracking”.

    From what I can see in the above, you are now running FW. 440.20
    I’ll assume you were prior on something earlier (?)

    Is you issue that the machine is moving, but the reported values are locked at 0.00?

    Is your flow control setting, $ex, consistent with what UGS requires?

    in reply to: 6wire 2phase 5Volt Steppers With Tiny G #12016
    cmcgrath5035
    Moderator

    Nope, If 10 TPI –> 1/10 = 0.1 travel per rev (as you note)
    So 8TPI –> 1/8 = 0.125

    As you have found by now, ist usualy requires a rest of tinyG for the changed parameters to take effect

    in reply to: TinyG Machine Status idle with Universal Gcode Sender #12009
    cmcgrath5035
    Moderator

    I could not read the most recent file, just sent an access request.

    A Parameter dump ($$ output) might help here.

    in reply to: 6wire 2phase 5Volt Steppers With Tiny G #12008
    cmcgrath5035
    Moderator

    Need to see the parameter setup.

    In coolterm, create a $$ listing.
    Copy the listing and paste it to a cloud file (Gdrive, dropbox, etc.) and provide a link.

    Have you read thru the configuration wiki?
    https://github.com/synthetos/TinyG/wiki/TinyG-Configuration-for-Firmware-Version-0.97

    don’t play with limit switches yet.
    I doubt your ribbon cable is cable is going to work.
    Limits very sensitive to noise, individual shielded pairs recommended

    in reply to: 6wire 2phase 5Volt Steppers With Tiny G #11995
    cmcgrath5035
    Moderator

    Z axis – can you freely rotate the Z axis lead screw with power off? with some z axis mechanisms, its easy to misalign and lock them up. That would lead to heating.
    Y axis – when you say it does not lock in place, do you mean it does not hold position when you move just X?. Do you get the same hissing (air leak) sound when you hit the reset button? On reset, all steppers that have $_pm=2 will be “in-cycle” for $mt seconds to hold the current position. Depending on stepper motor design, the could sound like an air leak.

    the V9 prototype will work well for a 4 axis task until something dies. There are many V9 prototypes out there so I would expect the G2 compiles to include the V9 binary, or you could compile your own.
    the gQuintec is really aimed at 3D printer applications and has some enhanced I/O and hi power control for heat beds and the like.
    But building a 3D machine from scratch is way beyond the scope of this forum.
    That said, if you have need for 5 axis control, gQuinctec might be a good choice.

    in reply to: 6wire 2phase 5Volt Steppers With Tiny G #11990
    cmcgrath5035
    Moderator

    Steppers sound fine. Those are essentially static measurement, if you pass 1.25A DC, the winding voltage will be 5.5V. Stepper drivers pulse current through the winding’s, e.g. 30V for 50ms at a time. You trim the tinyG POTS to move your machine adequately.

    See https://github.com/synthetos/TinyG/wiki/TinyG-Tuning

    V9 was dropped in favor of a 5 axis board with more modern drivers and a much more capable microcontroller. They are in final beta test

    See https://github.com/synthetos/g2/wiki/gQuintic-Specs

    in reply to: 6wire 2phase 5Volt Steppers With Tiny G #11988
    cmcgrath5035
    Moderator

    $fv=440.20 should get you going
    http://synthetos.github.io/

    in reply to: Homing cycle is not reliable #11986
    cmcgrath5035
    Moderator

    RE: your YouTube – Each enabled motor should display green leds for $mt seconds upon reset, that is, all motors will be energized to hold current 0,0,0 position for that period of time. For your setup, that should be 2 seconds. The flickering over long term is odd. The fact that the one led stays on longer than 2 seconds seems to say either a foreign voltage (off board) is making it back to the tinyG motor leads of, perhaps, the motor driver device has been compromised. Tray enabling all 4 motors and observed the 2 second led behavior.

    I had a chance finally to look closely at your homing sequence run, posted in your initial item.
    Looking at these three lines from your initial homing run.
    ——-
    ….
    {“sr”:{“posx”:-14.747,”mpox”:-14.747,”vel”:0.10}}
    {“sr”:{“posx”:150.000,”mpox”:150.000,”vel”:0.00}}
    {“sr”:{“posx”:0.000,”mpox”:0.000,”stat”:3,”dist”:0,”coor”:1}}
    ——-
    I’ll disagree that the homing was successful, at least as I understand your homing intentions.
    You have set the X(max) switch as the “home” for X.
    The end result of homing has set that location as X=0.
    From your setup parameters, you want to set the machine up with a X total range of 150, presumably you intend to operate the machine zero centered using the g55 coordinate system. So Xmax location should be 150, if I understand your intentions.
    It appears that the second to last “sr” above achieved that, but then
    in the final “sr” that has become the zero location.

    I also wonder if your manual pressing of the limit switches is adding confusion, as it seems to imply that only open or closed states matter.
    You may find that low-high and high low transitions are important to the the firmware. Try by manually jogging the machine away from the limits and re-sending your g28.2

    in reply to: TinyG Machine Status idle with Universal Gcode Sender #11985
    cmcgrath5035
    Moderator

    It would be helpful if you could be a bit more specific on what you call “UGS did track positions..”. Are you referring to the display of the tinyG streaming status messages?
    Keep in mind I am not super familiar with UGS but understand it to be slightly more enhanced than CootTerm but less display oriented than Chilipeppr or cnc.js

    A $$ parameter dump would be useful here, as it answers a bunch of setup questions. Best way to send the $$ dump is to copy the screen to a text file, upload that file to a cloud drive (gdrive, dropbox, etc) and provide a URL for that file.

    in reply to: Homing cycle is not reliable #11981
    cmcgrath5035
    Moderator

    When you run a g28.2 x0 and it completes correctly, what is the resulting X position? Seems it should be x=75, your Xmax parameter setting

    in reply to: Homing cycle is not reliable #11979
    cmcgrath5035
    Moderator

    There is a lot of info to look at, some quick suggestions
    Have you read wiki at https://github.com/synthetos/TinyG/wiki/Homing-and-Limits-Description-and-Operation ?

    You have enabled limits at X max, Y max, Z max, which is unusual, but should work.

    I travel is “-“, by convention, so Zmax should be 0 and Z min -75.
    It will take some deeper analysis to see if that explains some of your behavior

    in reply to: TinyG only receives CoolTerm text files from OSX #11977
    cmcgrath5035
    Moderator

    My recollection is that CoolTerm had better file delivery features than putty, at the time Cool Term was not available on Linux.

    Have you seen this https://github.com/synthetos/TinyG/wiki/TinyG-Sending-Files-with-CoolTerm

    Also this https://github.com/synthetos/TinyG/wiki/Connecting-TinyG

    I have run, a long while ago, Xon/Xoff as well.

    Comment somewhere on the Wiki that some Xon/Xoff port drivers did a better job than others implementing XonXoff.

    Sounds like you are on your way to success

    in reply to: TinyG only receives CoolTerm text files from OSX #11975
    cmcgrath5035
    Moderator

    RTS/CTS is generally one protocol. It is generally preferred over Xon/Xoff where many implementation inconsistencies have been reported. You might want to poke around a bit on how well Pi4 hardware implements what has rapidly become a fading flow control method.

    A bit of searching does not find a reliable answer to the question “does the Raspian USB driver provide RTS/CTS protocol support as required by CoolTerm?”

    Have you tried any other Linux terminal emulators, such as Putty?

    in reply to: TinyG only receives CoolTerm text files from OSX #11973
    cmcgrath5035
    Moderator

    I am assuming you mean Rich text Format when you say RTF.

    Your observation that Pi finished first leads me to think that flow control is not working properly.. What settings are you using for CoolTerm and TinyG?
    I would suggest that RTS (Request to Send) would be the best place to start.
    That would be Tiny G parameter $ex=2 and a proper setting at the Cool Term end.

    We see a lot of Pis in use interfacing TinyG, but most often as the SPJS machine when using Chilipeppr. SPJS implements software flow control based on buffer fill signalling and bypasses hardware flow control. CNCJS has a similar mechanism Your file is likely being sent to completion by the Pi, but what TinyG is actually working on is a mess of buffer overruns at the TinyG end.

    in reply to: TinyG Makes noise but stepper doesn't move #11971
    cmcgrath5035
    Moderator

    With $mt=2, all motors will power down after 2 sec at end of cycle, that is consistent with your comments about manual lockup on startup

    If you are going to home the Z axis (you have a switch turned on)
    then $ztn=-75 and $ztm=0
    By convention, Z homes to the top of travel at position zero and movement is negative from there

    Doe anything change movement wide if you temporarily set
    $1ma=2
    and
    $4ma=0
    swapping the X and Z axes?

    Try setting all homing to 0 until the motors are moving

Viewing 15 posts - 61 through 75 (of 1,771 total)