cmcgrath5035

Forum Replies Created

Viewing 15 posts - 526 through 540 (of 1,771 total)
  • Author
    Posts
  • in reply to: Universal Gcode sender cuts to big #10390
    cmcgrath5035
    Moderator

    I assume you are aware that moving , by jogging or just grabbing the spindle and moving by hand, then resetting tinyG should reset the current position to 0,0,0.

    in reply to: Universal Gcode sender cuts to big #10389
    cmcgrath5035
    Moderator

    OK, understand what you are doing.
    Good luck.

    in reply to: Estimating time accurately #10388
    cmcgrath5035
    Moderator

    I don’t know how to calculate it.

    You could create a simple Gcode file that makes the move, run it on tinyG with steppes disconnected or with spindle up (in air) and capture the return status stream, which will show the ramp up and ramp down in velocity.

    in reply to: Estimating time accurately #10385
    cmcgrath5035
    Moderator

    A general comment would be that the execution time of a given Gcode file is a complex combination of a lot of parameters plus , potentially, the performance of the Gcode delivery link. For example, Chilipeppr was initially developed to focus on keeping the motion planner as busy as possible and is buffer fill managed. G code delivered by UGS or CoolTerm might not run as fast.
    Most folks on this forum think in terms of XYZ CNC machines. Are you, or perhaps are you working on a complex motion robot?

    Can you bound your need for time estimation?
    A simple bound might be “How long can I walk away from the machine while the job runs”

    A complex bound might be a system that dynamically generates Gcode to compensate for motion that has just occurred.

    And, by the way, some Gcode might run a little faster on G2core than on tinyG because the compute engine has more horsepower, depending on the complexity of the effective tool path.
    What are you designing around?

    in reply to: Universal Gcode sender cuts to big #10384
    cmcgrath5035
    Moderator

    I don’t know jscut at all, but believe it supports cutter diameter compensation. Is that turned on perhaps?

    Looking back thru this thread, I see I don’t know a lot about your setup, e.g. the type of machine (belt, screw, other). This could be due to loose pulleys or mechanical couplings, that measure OK in linear direction, only x or only y, but simultaneous X and y cause things to slip.

    Also, I am assuming this is all focussed on a machine connected to a tinyG running FW 440.20, not G2core running on a DUE or something similar.

    Posting your tinyG settings (a $$ dump) to a cloud drive and providing a URL link would reveal a lot.

    in reply to: TinyG setup/configuration – file download #10378
    cmcgrath5035
    Moderator

    If you are Chilipeppr user, you can try this:

    Just dumping a text file seldom works well, you need to wait for tinyG to respond after each command is sent

    in reply to: TinyG hanging up in the middle of the job #10375
    cmcgrath5035
    Moderator

    All machine cabling is recommended to be shielded twisted pair cabling, with shields grounded at the tinyG end (not both ends, or the shield becomes a bigger antenna).

    I would also recommend separate power supplies for the spindle and for tinyG/steppers. A heavy spindle load current can cause it’s power supply to get noisy as well.

    in reply to: Universal Gcode sender cuts to big #10374
    cmcgrath5035
    Moderator

    So I assume
    you don’t need to adjust these for UGS as well. Or do you need to calibrate these settings for each type of Gcode sender ie chillipeppr and UGS?

    The $_tr settings are machine settings, dependent on the mechanical characteristics such as gear ratios or pulley/belt designs. What sort of machine do you have (belt, screw, etc)?

    The coordinates of actual movement are coded into the Gcode statements.

    UGS, at least the version I am familiar with, is a simple line by line file sending tool. It manages serial delivery of the Gcode statements between the sender machine and tinyG.
    Chilipeppr is a CAM software tool and could be programmed to modify Gcode dimensions on-the-fly, but I have not seen that feature implemented. An example of Chilipeppr on-the-fly modification would be the “Feedrate Modifier in the Gcode widget, which modifies the streaming Gcode “F” commands dynamically.

    You are loading the same (identical) Gcode file into UGS and Chilipeppr, correct?
    UGS running on Windows and on RaspberryPi should perform the same as well, have you tried that?

    in reply to: Fusion 360 Bore issue #10369
    cmcgrath5035
    Moderator

    I am not quite sure what you mean by

    board could not keep up with all the moves and started stuttering significantly. I may try moving the SPJS to the local machine

    For sure, SPJS is more efficient at keeping the tinyG planning buffer full, which will reduce buffer starvation and maintain fill as much as possible.

    Good Luck

    in reply to: How to prevent MINIMUM_TIME_MOVE error #10368
    cmcgrath5035
    Moderator

    Unfortunately, there is no one place and don’t expect a fully consistent set of rules.
    Have a look at this

    in reply to: How to prevent MINIMUM_TIME_MOVE error #10365
    cmcgrath5035
    Moderator

    You may find this wiki item helpful in general

    But looking there, I doubt you will get much more info on your specific question..

    I suggest you ask this question here:

    The issues interface is much closer to the developers (this is for the most part a user forum).

    I believe you assumptions on cause are generally correct, but details of the parameters that might affect it are unclear (to me).
    Are you perhaps hand coding G code to run your machine? You may not be following the ‘rules’, which themselves are somewhat difficult to interpret.

    in reply to: Connection Issues #10363
    cmcgrath5035
    Moderator

    My immediate thought on reading this was that possibly the USB connector on tinyG was somehow compromised mechanically or that the input ftdi device (USB to serial) on tinyG was somehow electrically damaged.

    Here is a link to the tinyGV8 schematics, you could try to check continuity from the input to the USB cable to the pins on the FT230x, particularly in the tinyG output path.

    The tinyG receive path could be receiving garbled pulses, but resetting tinyG should send the prompt message with no input commands upon reboot.

    You could try to bypass the FTDI front end using an offboard USB to Serial converter and connect to J14.

    in reply to: Fusion 360 Bore issue #10362
    cmcgrath5035
    Moderator

    Your job is likely hitting a bug/Gcode specification issue in tinyG.
    I assume you are running $fv=440.20.

    MM mode (G21) is sometimes a solution but you are already using G21.

    Next best suggestion is to regenerate your job with no arcs, which is reported to be possible with correct backend options.
    Unfortunately, no experience with F360 here, Google search might help.

    in reply to: Connection Issues #10359
    cmcgrath5035
    Moderator

    We probably need some specifics on what you a have.
    You talk about COM ports and VCP drivers, so one would assume your host computer is running Windows; what version?

    Has the combination of your current computer, it’s OS and tinyG ever worked?
    You speak of “recent” odd behavior, which I interpret to say it has been working OK until recently.
    An obvious question then might be what has changed?
    Do you recall what FW version “was” working on tinyG? By default most readers here will assume 440.20

    It is likely best to focus on getting the very basic CoolTerm interface working, Chilipeppr and SPJS add significantly to the complexity of what goes on and is unlikely to work if CoolTerm does not.
    For sure be certain that SPJS is not running on your computer when you use CoolTerm or there would be potential resource conflicts

    It would help if you could describe what you define as “I can connect to the board” when using CoolTerm. For example, When you connect CoolTerm, you appear to have a transmit connection to tinyG, the led flashes. If you then hit the reset button, does CoolTerm show any activity?
    tinyG FW, after it boots, sends an autonomous command prompt , something like “mm OK>” to the host.

    Have you tried a different PC?

    in reply to: Slipping/losing steps in Z axis #10357
    cmcgrath5035
    Moderator

    It should be easy to eliminate router noise form the discussion by running up and down with spindle off. From your discussion, I think you have already done that.

    If I rest my hand on the knob as it is moving (when it’s just doing a very slow, 2mm change), if I apply slight rotational pressure, I can easily move the knob until it reaches the correct number of position. Then it will “stick” there and hold.

    Have you tried rotating the Z between steps when it is not moving, i.e. is it easy to break the hold position with the hand wheel?
    Easier to do this up vs down?

    What are your Z motor and axis settings?

    Most ballscrews have larger travel per rotation that the threaded rods or ACME screws typically used for Z. The result is less mechanical torque amplification for the Z axis, meaning you might need more stepper current for Z if that is the case when using parameter sets intended for the ACME set ups (or rods) that are more typical.

    Reducing Z axis microstepping to 4 or even 2 might help as well, assuming you are using 8 at the moment.

    How how heavy is your spindle (router)?

Viewing 15 posts - 526 through 540 (of 1,771 total)