CNC troubles after update

Home › Forums › TinyG › TinyG Support › CNC troubles after update

Tagged: , , ,

Viewing 15 posts - 16 through 30 (of 37 total)
1 2 3
  • Author
    Posts
  • November 9, 2015 at 1:29 pm #8919
    Derrick
    Member

    1. With your current Parameter set, rerun a quick test that confirms that commanding Z to move 1 inch moves Z by 1 inch (or, as you reported, 0.9996″)
    I assume you are using a 1″ jog?
    Yes, I am using a 1in jog commanded via the ChiliPeppr interface. Doing so gives me a motion of .9995″. (I misspoke earlier, my digital calipers only give me the nearest .0005in).

    2. Change the $3mi parameter : $3mi=4 This cuts the number of microsteps per step in half.
    I changed the paramater as stated (it was set to a value of 8)… however still attain the same results, .9995″ of travel when commanding a 1″ travel via the ChiliPeppr jog widget.

    I have completed the actions as requested and saved the parameter file, it can be located here:
    https://dl.dropboxusercontent.com/u/183607375/CNC/TinyGConfig_20151109.txt

    November 9, 2015 at 5:15 pm #8920
    cmcgrath5035
    Moderator

    Comments
    1. Plenty of accuracy
    2. Changing the number of microsteps to 4 produced the correct results.
    TinyG computes the travel per microstep, then uses that value to determine how many step pulses to send to the motor driver. The motor driver is programmed by tinyG as to how many microsteps per step. So in this case tinyG sent half as many steps to the Z driver, but each step moved twice as far on each step pulse.

    Two issues are still to be worked: arc misinterpretation and the incorrect relationship between $3tr and reality; the Zaxis will move 2mm per motor revolution, but you need to set $3tr to 8mm to get a desired 1″ move for a 1″ jog.

    Let’s chase the Z axis first.

    First, two more questions popped up in my head
    1. Double check your motors – are they 1.8 degree Step Angle or 200 step per revolution? That is typical, but 400 step (0.9 deg step angle) do exist?
    That still would not explain your necessary *4 setting of $3tr, but would introduce a /2 error.
    2. Please try this mini test. Put your tinyG into mm mode (send a G21 command on the Serial Console), then jog 10 mm, 1mm at a time. We are testing to see if for some reason tinyG’s mm to inch conversion is broken. If jogging 10 times, each 1mm, only moves about 2.5mm (10/4), then the mm to inch conversion is broken.

    The Fix (I predict/hope)
    A. Connect CP to tinyG
    B. Make sure tinyG is in MM mode
    C. In the tinyG Serial Port Console, send a $defa=1 command
    This will clear and reset EEPROM and reset all your parameters to ‘factory default’. You might want to make a copy of $$ dump at this point so you can compare to the current parameters you just posted.
    D. Now one parameter at a time, enter the desired parameters in the Serial Port Console.
    E. when complete, hard reset tinyG (reset button)
    F. Reconnect CP to tinyG and dump $$ again to verify your work.
    G. Try your 1″ jog. If I am correct in running this ‘fix’, it will only jog 0.25″. You will then need to go back and change $3tr=2.0mm to get your 1″ move.
    H. you could try one of your multi-arc jobs again. It is possible that borked EEPROM could be affecting those computations as well.

    Then report back.

    • This reply was modified 9 years, 1 month ago by cmcgrath5035.
    November 10, 2015 at 10:16 pm #8925
    Derrick
    Member

    1. Double check your motors – are they 1.8 degree Step Angle or 200 step per revolution? That is typical, but 400 step (0.9 deg step angle) do exist?
    That still would not explain your necessary *4 setting of $3tr, but would introduce a /2 error.

    I double checked the documentation that came with them X/Y motors as well as the Z motor and all four motors are 1.8 degree step angle.

    2. Please try this mini test. Put your tinyG into mm mode (send a G21 command on the Serial Console), then jog 10 mm, 1mm at a time. We are testing to see if for some reason tinyG’s mm to inch conversion is broken. If jogging 10 times, each 1mm, only moves about 2.5mm (10/4), then the mm to inch conversion is broken.

    I completed the mini test and all is well, at least well in the sense of a 1mm jog command is equal to a 1mm travel in the Z-axis. The most it was ever off in the 10 moves was .05mm on the first move (and I think this was primarily due to my calipers settling a little bit. after the 10x 1mm jog commands the calipers were reading 10.01mm with 1mm steps along the way.

    I will continue on with your recommendations and report back.

    Derrick

    November 10, 2015 at 10:50 pm #8926
    Derrick
    Member

    One other thing that has been happening since I updated that I forgot to mention is that the TinyG seems to miss commands…

    What I mean by this is that if i select the jog button in ChiliPeppr and then move the machine using the arrows… it will start and stop or sometimes not start and require multiple key strokes to begin motion. This “missing” commands can also be seen when entering in command line, sometimes it will accept the command and continue, and other times it is like the board is not accepting commands at that time and I have to reenter the commands. This is not something that it did before.

    November 11, 2015 at 8:37 am #8927
    cmcgrath5035
    Moderator

    One other thing that has been happening since I updated that I forgot to mention is that the TinyG seems to miss commands…

    We’ll have to wait until you complete the $defa=1 process.
    If it in fact ‘fixes’ your situation, it is hard to predict how the current state might be affecting command execution.

    Keep in the back of your mind that commands that call for moves smaller than the minimum move do not result in machine motion, rather they are accumulated until a move is possible.
    An example:
    For your machine, with 1 revolution = 60mm move and 200 steps per revolution and 8 microsteps per step, the minimum move is 60/(200*8) = 0.0375mm in X direction. This is the distance moved when one step pulse is sent to the motor controller.
    If using the CP Jog interface set to 0.01, it will take 4 clicks of the jog to create motor response

    November 13, 2015 at 4:53 pm #8930
    Derrick
    Member

    I have completed the $defa process.

    The problem still persists.

    November 13, 2015 at 8:06 pm #8931
    cmcgrath5035
    Moderator

    Arc issue, Z axis travel issue, or both?

    Did you try these Gcodes:

    Please post an fresh $$ dump

    By the way, your Z axis motor is direct drive, correct (not belt drive)?

    • This reply was modified 9 years, 1 month ago by cmcgrath5035.
    November 13, 2015 at 10:20 pm #8933
    Derrick
    Member

    Arc issue and Z-axis travel issue (both).

    I ran another part that I needed cut for a project… fortunately not a precision part so stock settings were OK.

    Yes the Zaxis motor is direct drive. Personally I don’t really care that the z axis requires an odd steps per mm (4x what it should)… it works. I really need to get the arcs figured out, I have been unable to cut any parts that require accurate slots/tabs for nearly 2 weeks.

    FWIW: after the $defa I input all parameters in mm mode, as you mentioned earlier that it was TinyG liked this better.

    Here is a link to the latest dump file:
    https://dl.dropboxusercontent.com/u/183607375/CNC/TinyGConfig_20151113.txt

    November 14, 2015 at 8:21 am #8934
    cmcgrath5035
    Moderator

    Z-Axis – I completely understand your philosophy w.r.t. I have a setting that works, whether or not it is ‘correct’. Something is wrong/defective/miswired in your setup and it might come back to bite you later. If, for example, the microstep inputs to the motor driver were shorted or open(they are connected to two port pins on the tinyG MCU)it would create an offset between the number of pulses sent by tinyG to the motor controller, based on its computation of how far each pulse would move, an the motion created by the motor controller. But setting the $3mi=4 still tracked so something else is going on.
    One final request, then we will drop Z axis: With your finger, reach in and manually rotate the z axis roughly 1 rotation; does the spindle move roughly 2mm or roughly 8mm?

    Arcs (which I believe is Gcode related) – The file I have posted at

    is a mm mode version of your original .dxf file. Each of the circles is rendered as 2 180 deg arcs. The final dimension of the parts should be correct, if I did my conversion correctly.

    This will tell us that tinyG is capable of making your part correctly. If yes, then we need to figure out why tinyG is misinterpreting the Gcode you created when compared to the Gcode I created.

    Thanks for being the experimenter here

    November 14, 2015 at 9:00 am #8935
    Derrick
    Member

    One rotation is equal to 8mm of travel… I aligned the split of the flex coupling to the front and then rotated until it was in the front again, and it moved a total of 8mm over the single rotation.

    So it would seem that the machine is operating on the Z-axis as it should…

    I will give your code a try and see how it goes, and report back.

    One of the things that really has me baffled, is how it worked before the update and now it doesn’t… this indicates to me one of 2 things…

    1. Something in the update changed that caused the issue.
    2. The update firmware didn’t install correctly.

    Derrick

    November 14, 2015 at 9:08 am #8936
    Derrick
    Member

    I tried loading your file, however it is way to big, I assume 25.4 times to big… no mater the mode that the I have the machine set to, it always opens in inch mode (which is obviously incorrect).

    November 14, 2015 at 9:13 am #8937
    Derrick
    Member

    just to add a little to the Z-axis “problem”, or lack there of…

    Here is the product page:
    http://openbuildspartstore.com/8mm-metric-acme-lead-screw/

    Line from the description:
    Equipped with a large diameter that helps eliminate whipping and a high pitch which provides a quick 8mm translation for every revolution on the screw.

    November 14, 2015 at 12:06 pm #8938
    cmcgrath5035
    Moderator

    Z axis – Ah so, I am unfamiliar with the terminology they are using, but , upon looking closely, can see the long travel per rotation. SO “lead=8mm” is the key term. Thanks for the ACME screw education.

    Arcs – yup, I scaled it 1ncorrectly

    Try this one, I dragged it in to CP and the extents look OK in 3D viewer
    Machine will be in MM mode when it runs.

    November 14, 2015 at 4:11 pm #8939
    Derrick
    Member

    That code ran and produced arcs as it should.

    November 15, 2015 at 7:08 am #8942
    cmcgrath5035
    Moderator

    One of the things that really has me baffled, is how it worked before the update and now it doesn’t… this indicates to me one of 2 things…

    1. Something in the update changed that caused the issue.
    2. The update firmware didn’t install correctly.

    I believe your install is now OK and parameters are correctly set.

    As to item #1, I suspect an accumulation of arc move improvements you are now seeing in 440.20 has resulted in your original Gcode file no longer being compatible with the Gcode interpreter in tinyG.
    That may be a bug in tinyG or may be a bug(or settings issue) in CamBam.
    I will pass the Gcode file to the Devs for analysis

    To me, the banshee_control_horn_3.nc looks to be overly complex, with three or 4 arcs making up each circle. I have an idea why that might be, am not sure and won’t waste space here with the discussion.

    While the devs chew on this, you could proceed using CamBam in ‘short segment’ mode.
    You might also look for a CAD environment that includes a direct Gcode output capability.
    If you use short segment mode, keep in mind that the minimum X or Y move your machine can make is 60/(200*8)=0.0375mm. It does not make a whole lot of sense to generate segments that are significantly shorter than 0.01 or 0.02mm, as such short moves will simply be accumulated until a 0.0375mm move can be sent to the motors.

    You are by no means the first to experience an issue similar to this.
    Sometimes it is a bug, sometime a rework of the tool chain.
    Keep in touch if you find “a better way to do it”.

    For ease of location, this is the Gcode file that will not run properly, I am repeating it here so the Devs can easily grab it.

  • Author
    Posts
Viewing 15 posts - 16 through 30 (of 37 total)
1 2 3
  • You must be logged in to reply to this topic.