cmcgrath5035

Forum Replies Created

Viewing 15 posts - 1,231 through 1,245 (of 1,771 total)
  • Author
    Posts
  • in reply to: USB cable melting and catching on fire. #7903
    cmcgrath5035
    Moderator

    My 1 second guess is a foreign voltage offset between tinyG GND and computer GND.
    Since you have plenty of experience, I’ll skip the longer BE CAREFUL lecture.

    I have seen some weird effects of the interconnection of multiple “floating” power supply bricks.

    I think I would start with checking GND to GND potential with both AC and DC voltmeters with no connection between the tinyG and the computer

    in reply to: Newb Help needed #7902
    cmcgrath5035
    Moderator

    I am a bit stumped too.
    I don’t think it is your motors.
    Something is borked in the internals of your tinyG application, or perhaps tinyG hardware.
    Since we are hacking here, try this:
    Step 0 – The next step will wipe out our parameter set, so make sure you have a copy of your current settings.
    By the way, how did you first enter your tinyG parameters?
    Step 1 – Start up tinyG and terminal. If you can, capture your terminal session to a log file
    Step 2 – I typically enter a $ or ? command just to verify good interface behavior, you get some short status/parameter listings.
    Step 3 – Enter the command $defa=1 and enter.This step will perform a ‘factory reset’ of your tinyG, restoring a set of default compiled in parameters to EEPROM
    Step 4 – Run $$ command, then use command interface to reset your parameters to the values you have been testing with and try again.
    Step 5 – Post your terminal log if you made one

    in reply to: ADC input #7899
    cmcgrath5035
    Moderator

    You’ll get faster response if you post this over here as a Feature Request

    That is where the devs hang out

    in reply to: Newb Help needed #7898
    cmcgrath5035
    Moderator

    So what OS are you running? The $$dump is really hard to read with the funky spacing, but I could edit it to be more useful.

    I suggest you turn homing off until you have a machine connected.
    $xsn, $ysn, $zsm and $asn = 0.

    No way should you get thermal shutdown in your current setup – unloaded steppers require very little current to spin when unloaded. So that is not the cause.

    Try this:
    Reset your tinyG, it will come up in mm mode ([gun] default gcode units mode 1 [0=G20,1=G21])

    From command line, enter
    G0 X125
    Your X motor should turn 100 revolutions
    G0 X-125
    Your X motor should turn 100 revs in the other direction.
    Likewise play with Y and Z.

    Just trying to make sure motors are connected correctly.

    No need for fans.
    To be honest, the tinyG shutting down with the fan connected makes no sense at all.
    Can you monitor your power supply voltages while this is running?
    Could be a bad PS, I suppose.

    If you try using Chilipeppr, you could issue these commands in the Serial Port Console (lower left) or you could use the Jog widget

    in reply to: TinyG Connection Issues #7897
    cmcgrath5035
    Moderator

    Another test you should run, if you have a voltmeter:

    Measure the voltage at each XYZ switch port on the tinyG, while manually activating the switches with your finger.
    Are states changing as expected?

    in reply to: Newb Help needed #7891
    cmcgrath5035
    Moderator

    Barry
    If I had to guess, you may be experiencing thermal shutdown of the drivers, but that is somewhat a wild guess.

    First up
    1. We need to see your full parameter set, the results of a $$ command. Here is the most useful way for you to post it:

    2. Your parameter set will report what Firmware build you have on your tinyG. If not already, you will want to upgrade to fw 440.14.

    3. Since you mention tgFX, I’ll assume you are running from a Windows PC?
    tgFX is no longer supported and likely has issues interoperating with fw 440.14. If you want to run a GUI, I’d suggest you give ChiliPeppr a good look

    As a side note, when I connect a 12v .45amp PC case fan, the tinyg becomes unresponsive and Windows reports that it has malfunctioned. I tried two different fans and had the same result. The fans blow fine while connected.

    Are you powering the fan from the tinyG fan header? Have you set the voltage jumper for 12V? I wonder if the 12 v fan is actually being fed 24V and dragging down that power supply. Otherwise, I can’t explain the behavior.

    Does your job run in air (not cutting)?
    Perhaps you are milling too fast, although F2.5 is rather slow already.
    What are you milling?(wood, AL, foam, ?)

    • This reply was modified 9 years, 2 months ago by cmcgrath5035.
    in reply to: TinyG Connection Issues #7890
    cmcgrath5035
    Moderator

    OK, now see Dump2.pdf. Settings look good for starters.

    Your description is very readable, but hard to understand.
    Keep in mind that “left” and “right” are subjective and that many OX machines have a different default definition of where 0,0,0 is located, when compared to typical ShapeOko machines, so readers can get very confused. Likewise, the terms “front” and “back” are subjective and based on the readers frame of reference.

    I am not a homing user yet, so these questions are based on how I think I would debug your situation.

    Manually put you gantry in the center of the workspace and set that as 0,0,0.
    1. when you issue G0 X10, does gantry move 10 mm away from the X homing Switch.
    2. When you issue G0 X-10, does they gantry then move 20 mm toward the homing switch?
    3. Likewise for Y and Z axis.
    I expect you see what I am asking – are the switches located at Xmin, Ymin and Zmax?

    Next question would be, are you sure that the Xswitch is connected to the Xport on TinyG (Y and Z as well)?

    I would also suggest you start a separate (new ) thread. You seem to be connected and basically operational for now, so a topic such as “TinyG homing issues”, with a terse description of your setup, a repost of the link to settings and results of you homing attempts might attract others with homing experience.

    Homing works for many (most discussion is is on the Chilipeppr sites these days) so I suspect some sort of configuration issue with you switch setup.

    in reply to: TinyG Connection Issues #7887
    cmcgrath5035
    Moderator

    Hmm, I looked in your dropbox location and see no Dump2 file, I see 4 files all 32 hours old.
    OK, you had 3mm belts so $_tr=60 is correct for 20 tooth pulley

    What I do see (in the $_tr=1.25mm dump) are NO switches set up a homing on Xmin and Ymin, homing and limit on Zmax. As such, look OK

    Are you sure they are NO?
    What command are you using to attempt homing?
    Using command line or CP?

    If you issue just a home X axis, what happens, nothing?
    No movement, no flashing leds?

    in reply to: TinyG suddenly misbehaving #7884
    cmcgrath5035
    Moderator

    Details, details, details, so many details. of CP is in the way it manages the flow if data to, and status back, from tinyG .

    Much of the power of CP is in the way it manages the flow of data to, and status back, from tinyG . All of that is enabled by the choice of SPJS engine handler, “tinyg”.

    If have not yet, upgrade to SPJS 1.82. Much faster/more efficient.

    in reply to: TinyG Connection Issues #7883
    cmcgrath5035
    Moderator

    For sure Chilipeppr has a learning curve, but is feature rich and being actively used and improved.

    You have an Ox machine, which is belt drives, correct?
    NEMA23 Motors?
    Your $1tr, $2tr and $3tr = 1.25mm look strange, I normally see =40mm for this sort of machine. How did you come up with 1.25mm?

    in reply to: TinyG Updater App Problems #7880
    cmcgrath5035
    Moderator

    Thomas – Lets continue on the CP Community, since you and Kurt ( and probably others) have the same issues there.

    in reply to: Fix for weird Gode scaling with TinyG? #7879
    cmcgrath5035
    Moderator

    Just for the record, I’ll document your find that $_tr was set for 2mm but in fact they were 8 mm lead screws.
    So setting $_tr=8mm corrected the behavior.

    in reply to: 5th motor #7878
    cmcgrath5035
    Moderator

    For using tinyG, I would suggest your 2 external driver method. Not many folks have experimented with the networked tinyGs approach and there is not much development on that path.
    TinyG outputs 3.3 volt logic, so the need to buffer the Step and Dir leads will depend on the input requirements of your chosen drivers.
    Make sure you consider how to reverse the direction of one of the two Y motors, as the polarity setting in tinyG won’t do it for you.
    And, be sure to set the microsteps on the external drivers consistently with what tinyG is set for as well

    If you want to pursue a more bleeding edge approach, you could try tinyG2, running on a DUE, with 5 external drivers. There is a lot of active development on that path. TinyG2 has the performance and connectivity for up to 6 motors.

    in reply to: FW update problems #7877
    cmcgrath5035
    Moderator

    The tinyG Updater app will initiate the “Automatic Reset” if you select the “Attempt automatic Reset” box in the updater GUI; you should not need to manually reset.

    Reference:

    in reply to: JSON help needed #7876
    cmcgrath5035
    Moderator

    Compare the $sv and $si parameter values between the two tinyG setups
    Reference

Viewing 15 posts - 1,231 through 1,245 (of 1,771 total)