cmcgrath5035

Forum Replies Created

Viewing 15 posts - 586 through 600 (of 1,771 total)
  • Author
    Posts
  • in reply to: TinyG USB not working properly #10209
    cmcgrath5035
    Moderator

    All the tests you describe seem to indicate a properly booting tinyG.
    FYI, the USB interface on tinyG is all hardware – microcoded into the FTDI device on-board. So the USB device should show up when plugged in as long as it is powered up, irrespective of the FW sanity of the tinyG FW on the board.

    Have you tried different, known good USB cables?
    Are you plugging into a USB2 port? Some early USB3 ports had issues.
    Have friends with Linux running? FTDI support is native with most Linux OSs.

    Possibilities include USB port issues on PCs, FTDI device issue, connector issue on tinyG and defective USB cable.

    If you have exhausted PC and USB cable testing, then you’ll have to get a replacement unit from Adafruit I suppose, or perhaps directly from Synthetos. You can contact Synthetos customer service at

    in reply to: Wiring an NPN NC inductive proximity switch #10206
    cmcgrath5035
    Moderator

    SSRs are typically for Power switching – e.g. turning off 110V or 220V mains with logic.
    Would be overkill for limit switch interface.
    They can be useful for on/off control of small routers when used as spindles.

    in reply to: Wiring an NPN NC inductive proximity switch #10204
    cmcgrath5035
    Moderator

    I scraped this from the URL you provided:

    M12 Cylinder inductive proximity switch LJ12A3-4-Z/EX sensing range 4mm non-flush 2wires system NO 6-36VDC

    Here is a URL for a typical NPN prox sensor

    From my quick look at your URL, you purchased a “NO” (normal open) switch.

    If your switch was a “NC”, the circuit diagram would possibly work with the issue I raised, and you correctly understand, that the 4170 ohm pulldown load may not be adequate to ensure that the Vin is a maximum of 3.3v under all conditions.

    The tinyG ports have a pull-up resistor on the PCB, for tinyGV8h that pullup is 2.7Kohms

    So when no switch is connected to a port pin, the port voltage is held high state.

    There are many solutions folks have implemented.

    IF you did have a NC prox switch, connecting a diode between the port pin and the output of the prox switch would work. Anode of the diode to the port pin, Cathode of the diode to prox switch. Diode would allow a low state prox switch to pull the port down to 0.7V (assume silicon diode) but would block 12V from the port pin, assuming you chose a diode with adequate Vreverse, like 20V.

    IF you want to use your NO switch, you need to invert the signal. Here are some ways

    The Opto-Isolator method is by far the safest, the opto isolates the 3.3V logic world from the 12V world. NOTE that the diagram above is for an Arduino UNO, which is 5V logic, you would reduce the “Arduino +5” to 3.3V for tinyGV8.

    Hope that helps

    in reply to: Wiring an NPN NC inductive proximity switch #10202
    cmcgrath5035
    Moderator

    I think I know what you want to do, but your description has me a bit confused.

    Specifically – if you have an “NPN” proximity switch, I would expect the the output lead to be near zero, the closed state (“NC”)when not operated, and I would expect the output to rise to 12V when the proximity switch is activated.

    It might be helpful if you post a URL or PDF of the specific device you are considering.

    Looking at your schematic , you are using a 4170 ohm resistor (270+3.9K) to pull down on the internal pullup in the proximity switch. There is some risk that the effective pull up resistance of the prox switch might vary and could result in more than 3.3v input to tinyG .

    in reply to: Manually turn steppers #10199
    cmcgrath5035
    Moderator

    Ah yes, I agree with kiwigrant, I sort of left out a step.

    After a zero point is set, by draging the gantry to X,Y 0,0 point, then setting the Z=0 point, I generally just hit the tinyG reset button, a new (0,0,0) point is established.

    in reply to: Manually turn steppers #10197
    cmcgrath5035
    Moderator

    Moving motors manually should not damage tinyG.
    Folks with belt machines (Ox, ShapeOko, etc) frequently use the “grab the gantry and move it to a zero point” method rather than implement homing switches. It is more difficult to do this with screw machines, due to the mechanical differences.
    Likewise, using a hand wheel on the Z axis to set a zero point, rather than using a Touch Block or probe cycle is common

    in reply to: PWM Not Working #10192
    cmcgrath5035
    Moderator

    There are two Spindle control outputs
    Spin – an ON/OFF signal(3V logic) suitable for driving an SSR or similar to control a single speed spindle
    SpinPWM – a PWM output (3V logic) suitable for interfacing a PWM controller

    Both pins have on-board LEDs from output to ground, so if the LED is illuminated, there is voltage on the pin.

    SpinPWM is just pulses – you can’t really measure with a VOM (multimeter).

    Read over this item

    When you come back, describe what sort of controller you have – PWM or ON/OFF.
    Research a bit the interface requirements of the controller you have – does it require 5v logic? If so, so will have to level shift the PWM signal or the Spin on/off signal.

    And provide a dump of your PWM parameters, by entering a $p1 command

    None of this directly addresses your ‘spark’ directly, which usually means something fried.

    • This reply was modified 7 years, 10 months ago by cmcgrath5035.
    in reply to: Stable g2 firmware on Arduino Due #10190
    cmcgrath5035
    Moderator

    OK, you discovered Issues which might help.

    There does not seem to be a large community of MacOS users, and some of the MacOS issues seem to be in OS drivers, etc that Win and Linux folks are unfamiliar with.

    The G2 Wiki has several items focussed on parameters and tweaking,
    Beyond that, I would say that the Ox forum has a lot of G2 experimenters.
    Be sure to describe your machine – (belt, screw, etc.).

    in reply to: Maximum Jerk $xjm=0 Question / support case #10189
    cmcgrath5035
    Moderator

    I have never seen that question asked before.
    I might suggest you open an Issue here:

    The devs hang out there, as do many super users (folks highly customizing tinyG code)

    in reply to: tinyG headers. Enable active low? #10185
    cmcgrath5035
    Moderator

    TinyG has been around for a while, and was 4-on-board-drivers centric.
    Folks pushing the envelope added external drivers to the mix, and accommodating pins were added.
    GRBL is only 3 motor processing(I believe), but you are correct that G2/DUE are worth considering for users targeting external drivers (up to 6 motors).
    If your chosen external drivers are 5V logic you will have to buffer and level translate DUE as well.

    Enable active low is likely a side effect of using TI drivers.

    in reply to: Stable g2 firmware on Arduino Due #10184
    cmcgrath5035
    Moderator

    TinyG-Updater is for tinyG only; DUE requires a different tool chain.

    The G2 Wiki has straightforward how-to for downloading.

    G2 is under continuous development, so I’m not sure what you would consider “latest stable” release. Each new release has bug fixes and new features.

    There is not a whole lot of G2 traffic here. You might want to peruse

    to see what others are up to and are finding.

    If you want to play in G2, I suggest you follow the wiki and set up a local build environment. Then you can compile what ever version you might want to try. Building on both Linux (native tools) and on Windows (Atmel tool chain) both work well (past experience).

    There are numerous ‘power users’ on the Ox forum and on Chilipeppr that discuss G2 based systems; many of them are heavily customized by the users.

    Good Luck with the adventure.

    in reply to: Arc interpretation error? (G3 / G2) #10181
    cmcgrath5035
    Moderator

    I’ll assume your tinyG is running Firmware 440.20.
    It is the best at this, but there are still bug(s) related to arcs

    Possible short term solutions
    1. I can’t tell for sure if your Gcode is mm or inch. If it is inch, try regenerating in mm; mm always works better. TinyG is native mm, so inch Gcode gets a lot of translation manipulation.
    Recognizing the rather large numbers 48, 54, etc, I am guessing you are already mm (or have a really big machine)
    2. To get your job done, try to generate the Gcode without arcs. I’m not sure if HSM has that option. You will get a Gcode file with arcs replaced by short G1 moves.

    in reply to: X axis on right side #10178
    cmcgrath5035
    Moderator

    I a little confused – the parameter dump you attached has Xmin set up as homing. -?

    Also, I am not sure what you mean by ” the code to get it to home correctly,”
    Did you hand code a homing sequence?
    Parameter files are real tough to review via this forum tool.
    Better to place the parameter dump (all of it, including the offsets section) into a Cloud drive (dropbox, Gdrive, etc) and provide a URL for viewing.

    I think what you want can be done, but you may need to create your Gcode design in the (-X,+Y) quadrant of the 2D design space.

    in reply to: Compiling firmware for TinyG? #10176
    cmcgrath5035
    Moderator

    Assuming you are compiling the tinyG (not G2) project, you might want to post an Issue here:

    We don’t see much forum traffic on compile issues.
    You can also review open and closed issues for helpful hints

    in reply to: Types of TinyG JSON responses/reports #10170
    cmcgrath5035
    Moderator

    Here is a discussion on ‘er’ message formats

    I have seen no other report types, but don’t dig as deep as you are.
    You might get more info posting an Issue here:

Viewing 15 posts - 586 through 600 (of 1,771 total)