cmcgrath5035

Forum Replies Created

Viewing 15 posts - 406 through 420 (of 1,771 total)
  • Author
    Posts
  • in reply to: Y Min Input Not Working #10738
    cmcgrath5035
    Moderator

    In your parameters,
    [ysn] y switch min 0 [0=off,1=homing,2=limit,3=limit+homing]

    Is this perhaps because you were experimenting withsettings?
    Appears your parameter set says home to Ymax – ?

    But those settings would not affect your Ymin = .11 V open circuit (switch open).
    There is something shorting the pin to ground, almost as ‘short’ as a closed switch.
    Solder blob, leaky/defective 0.22ufCap, other board defect could be responsible.
    As a final test, remove the wire from the Ymin terminal, Still read about 0.11V on the terminal screw. If so, something defective on board.
    Contact Synthetos again, “Ymin terminal shorted to ground” on new tinyG, add a link to this thread

    in reply to: Y Min Input Not Working #10735
    cmcgrath5035
    Moderator

    Me again
    Here is a copy of the schematic page for a tinygV8h, the most recent
    https://github.com/synthetos/TinyG/blob/master/hardware/v8schematics/v8h/tinyGv8h%20-%20schematic%20page1.pdf
    As you can see, All Max/Min ports are pulled high (3.3v) by a 2.7k resistor and bypassed to ground by .22uF. This provides some degree of noise conditioning for the lead.
    I’ll assume you have a VOM or DVM. with tinyG energized (does not have to be moving), probe the Ymin lead at tinyG while you operate, then release the limit switch, monitoring the voltage. It should toggle between 3.3v and ground.

    From your original message, I am assuming that you ran a test sending Y from some position toward 0 and axis hit the limit switch but kept driving the motor.

    So now, with tinyG energised but the motors relaxed (by default, this is two seconds after a reset), manually move your Y toward 0 and observe the voltage at Ymin. Is the gantry movement mechanically triggering the switch, causing Ymin to go from ground to 3.3V(on voltmeter)

    It may be helpful if you post your parameter settings for a look.
    Run $$, copy the results to a cloud drive file and post URL for us to look.

    • This reply was modified 6 years, 10 months ago by cmcgrath5035.
    in reply to: X axis travels ~10 times more than it should #10732
    cmcgrath5035
    Moderator

    Ah so, I missed this:
    here is the Spindle Thomas has

    I have not seen that setup before, appears to be a 500W supply with built in output controller.

    You need to get the wiring info, as it is unclear how the switch interface works

    Question:
    Is there a wiring diagram for the power supply?
    Answer:
    the product photos on this page include a picture of the wiring diagram.
    By iskum kloshe on March 18, 2017
    Yes, we have, pls contact us by bigbangamazon@yahoo.com this email, we will send it to you, thanks.
    By MySweety SELLER on January 9, 2017
    Collapse all answers

    Be aware that Mach4/Mach4 use different control interface than tinyG, so some fiddling or relays (opto-isolators) may be required.

    in reply to: X axis travels ~10 times more than it should #10731
    cmcgrath5035
    Moderator

    What Zootalaws does not see on this thread that was on prior thread is that, the way I read your info, the machine was moving properly with these settings. Perhaps I jumped to that conclusion prematurely.

    From you initial thread, and the flashing re leds, it sounded like you have shorted or somehow electrically corrupted the EEPROM or possibly flash.
    Here is Thomas’ most recent email

    So I was just able to take some time and play with this. I was able to get the $$ command to work right from the start. (It could be that the other times I tried to use it was after using the TinyG for a while and I overloaded the communication . Not sure…)
    I did the recommended :$defa=1, and it did reset to defaults; however it was not successful. M1 still over travels. I did download the firmware GUI from the website and I was able to load in the latest firmware, same result. When I did this, none of my parameters changed. The firmware number was the exact same as what I had loaded on my board so maybe it didn’t actually load because it realized it was already up to date?
    I will upload my parameters like you suggested: “If issues continue, copy your full parameter set ($$) to a cloud drive and post a URL for viewing in a new Forum item at …” as soon as I get to my computer this morning.

    Quick question about how I hooked up my spindle on/off:
    I wired from the “SPIN” pin, out to the spindle power supply on/off switch, and back to a “GND” pin on the TinyG. I know this was wrong because of what happened, but should I have wired to “3.3v” instead of “GND”? OR should I have used a relay? I found very little explaining how that pin functions. I did measure the spindle power supply switch prior to hooking up and it measure 0v across as well as to ground so I don’t believe I supplied an outside voltage to the “SPIN” pin.

    From you extended description, I still have to worry about electrical damage.
    The SPIN lead is a 3.3v logic signal from the controller. It “might” be able to turn an opto-isolator switch on and off, but for sure can source or sink much power. I have not see an opto-isolator controlled Spindle Power Supply, but they for sure could exist. Perhaps just post a Model number or easier, a URL to where you bought it.

    Can I assume you have seen the tinyG wiki at https://github.com/synthetos/TinyG/wiki ?

    To summarize, as said above SPIN is logic on(high) off(low)
    SPWM is 3v logic PWM interface to variable speed controllers.
    Spindle control is via Gcode M3 and M5 commands.

    Can we assume that you manually loaded the parameters you provided?
    They are somewhat unusual.
    I see very few folks with $_sa=0.9 degree motors, but they do exist.
    Depending on which FW loader you used I think it would be clear if your FW re-install did not work.
    All that said, I would expect the FW version to be the same (440.20) and if you do not see changes in the parameters, that implies we are looking at the default parameter set. But I don’t think the defaults have $_sa=0.9, so I am curious.

    When you come back, please comment on your parameters and where they come from. Are you following a guide for a particular machine?
    What are you using to interface to tinyG? PC, MAC, etc
    Using CoolTerm or perhaps Chilipeppr or other?
    Also, provide more info on wiring SPIN to your power supply control.
    What you report implies reasonable functionality, communications wise, which seems to rule out SPIN having experienced a 120V AC event, which I would expect to be rather catastrophic.

    in reply to: HeatSinks #10730
    cmcgrath5035
    Moderator

    The RasPi style sticky tape heatsinks won’t hurt but are not nearly as effective as cooling the board (bottom best, top almost as good). Drivers are in ‘heat slug’ packages and well connected to the board ground plane for dissipation and heat spreading.

    Zootalaws has provided a good and easy to perform test (easy for me to say, it’s your finger). If having performed it, you think you are close to “bloody hell”, then try running you Gcode job above the workpiece (“run in air”) and see if tinyG still seems too hot. With no load (machine load only), things should stay cool to touch.

    From you extended description of situation, I don’t think thermal shutdown is your issue. True thermal shutdown (by the individual driver devices) is most un-elegant, sort of like a self healing thermal fuse. Motors do get a bit cranky when really hot, does X stepper feel >> warmer than Ys or Z?

    tinyG missing steps, particularly on certain arc moves, is an on and off problem for some folks.
    How do you generate Gcode?
    Is this a new issue (a new design) that always fails?
    Inch or mm?
    If inch, try generating in mm and re-run. Most of the Arc issues seem to ultimately due to loss of math precision by the 8 bit cpu, made worse by numerous inch to mm to inch on the fly conversions. tinyG does it’s internals in mm, so inch Gcode sees a lot of conversions.
    If mm still fails, you could try to generate Gcode without arcs, if your system supports that.

    If you are still having issues, a look at your parameter set ($$) and a Gcode listing from the vicinity of the skip, if you can isolate it, might help. Copy these to a Cloud drive and post a URL.

    in reply to: TinyG failing at corners #10724
    cmcgrath5035
    Moderator

    Hmmm, the only reference I see to “Bad number format” uses the example of G0 X1..23 rather than G01.23, basically a typo entering Gcode.
    That is unlikely with generated Gcode, e.g. F360.

    Are you able to locate a line of Gcode in your file that includes “X76.16 Y99.703 Z8”?
    Perhaps the offending “Bad Number” is near this line, sitting in the buffer having been pre-fetched by the planner.

    I recall (can’t locate the thread) someone commenting that using the F360 post processor to reduce the number of digits beyond the decimal point from 4 to 3 (or perhaps 2) resolved some unusual behavior.
    Also, these lines of Gcode from your first post in this thread do look strange

    tinyg [inch] ok>
    X3.05 9868IX3..4229 I0.0355 J0.0476 Y3.952.5 J0.04J0476 Z0.3968 I0.
    tinyg [inch] err: Bad number format: X3.05 9868IX3..4229 I0.0355 J0.0476 Y3.952.5 J0.04J0476 Z0.3968 I0.

    Can you provide a segment of your Gcode before and after the offending line?

    I don’t trust the auto formatting that goes on with this web tool – better to put the code in a Cloud drive text file and provide a URL

    in reply to: HeatSinks #10723
    cmcgrath5035
    Moderator

    The bottom layer of the board is 2oz copper ground plane and well connected, thermally, to the driver devices.
    Fans on bottom work well
    Something like this works well too
    https://drive.google.com/file/d/1152ojWcgC9dErvgmYjxY-RIjGCZL62P1gA/view?usp=sharing

    in reply to: TinyG and PCB mill #10720
    cmcgrath5035
    Moderator

    I would Start by looking at CNCJS, https://github.com/cncjs/cncjs/wiki
    It is similar in some respects to Chilipeppr, but I don’t believe it has the PC board widgets that work well in Chilipeppr. At least not yet.

    It runs on Node.js on local machine

    in reply to: TinyG for 5 or 6 axes soon? #10716
    cmcgrath5035
    Moderator

    A five driver single board unit is in development.
    It is 3D printer centric and has additional I/O capability when compared to tinyGV8
    It will run G2core
    There is no firm schedule as of yet.
    You could start with an Arduino DUE and external drivers.

    in reply to: TinyG failing at corners #10714
    cmcgrath5035
    Moderator

    tinyG is Fussy about Arcs, the beginning of one arc and the end of the prior must meet certain criteria. Ultimately, this can be cause by a math precision error.

    Frequently, regenerating the design using mm, rather than inch, will resolve it.

    in reply to: Issue with M4 #10711
    cmcgrath5035
    Moderator

    $m4tr=360mm is likely not correct, when compared to $m2tr=$m3tr=1.25mm.
    Of course I am thinking CNC machine, you could have some other very different configuration.
    So if G0 X1 Y1 were sent, X axis would move 1.25/360 as far as Y axis, then hold on to its position and hum for $mt=2 seconds

    The rest of your settings look OK after quick look.

    in reply to: control fan speed #10707
    cmcgrath5035
    Moderator

    Are you sure that J12 is configured to output 12V on J11?

    The most effective way to control fan speeds is a pwm controller in series with the fan.
    Something like this https://www.amazon.com/IDS-Voltage-Controller-1803BK-Adjustable/dp/B073H73JRG/ref=sr_1_21?s=grocery&ie=UTF8&qid=1513826219&sr=8-21&keywords=pwm+fan+speed+control

    Of course, it might be more cost effective to buy a quieter fan

    • This reply was modified 6 years, 11 months ago by cmcgrath5035.
    in reply to: Stable g2 firmware on Arduino Due #10702
    cmcgrath5035
    Moderator

    cbarbre: It is not clear to me what you are asking about.
    It reads like you want to install $fb=078.03 on a DUE, which should be straightforward using bossac tools.
    What is your working environment – MAC, Linux, Win?

    What is your ultimate goal – build a machine or just experiment with G2core’s capabilities?

    $fb=078.03 is dated FW and there are significant updates and enhancements in the most current Edge build, $fb=100.26
    The time you spend now to build your own DUE+gShield binary, and to understand the G2core build system, will save you a lot of time in the long run, if your goal is to actually build and operate a machine. There will be no further updates to $fb=078.03 $fv=0.97 code, sooner or later you will want to move to 100.26 or later.

    in reply to: TinyG stopped working #10699
    cmcgrath5035
    Moderator

    Good find!
    Thanks for closing the issue

    in reply to: TinyG stopped working #10696
    cmcgrath5035
    Moderator

    Hmmm, strange.
    The only thing that happens on the CNC is the steppers go into hold mode for the duration of the logo run.

    I am not clear on what you are seeing, aside from the steppers not moving.
    What I think I am reading is that after you continue following the pause, CP sends the complete gCode file, the 3D viewer traces around the design on screen?
    Do you see the status messages scrolling in the Serial Port Console widget?
    When the gCode file completes, are you able to again jog the machine, or are the motors still disabled?
    I am assuming you are running a tinyGV8 and $fb=440.20, correct?

Viewing 15 posts - 406 through 420 (of 1,771 total)