Forum Replies Created
-
AuthorPosts
-
aldenMember
Thanks for bringing this up and documenting so well. I’ll run the same tests and chase this down.
aldenMemberThere is no reference but it’s simple. Get Coolterm for windows or mac from Roger Meier’s software page. Connect to your grbl/Arduino via the Options/Serial Port Options dialog. Grbl speaks at 9600 baud. Use re-scan serial ports to find your port. Hit Connect. Hit the CR a few times. You should get “ok” from grbl. They you can enter $ commands and Gcode lines.
aldenMemberTry setting the pots to their middle position (12:00 position) and repeat. That should be the position they were set before shipment. Check the pots to see if they are damaged. Do the screw slots look “clean”, or are they stripped, which is usually an indication that the pot was damaged.
If I understand correctly the Z axis “swap” sounds like software, not hardware. I’m not completely sure what you experienced. You enter a Y movement and you get the Z motor moving? You might try driving grbl directly from Coolterm and taking Gcode sender out of the picture. One less variable. Also, if you have an oscilloscope or a logic analyzer check that the arduino is delivering the proper step and direction signals.
We have seen only 1 unit that went out (out of 100’s) that had a manufacturing issue, but that doesn’t mean it can’t happen. They are all fully tested for all motor movement in both directions before shipment.
aldenMemberWe are still using Studio4. We tried 5 and it was buggy, and ultimately more clicks to get through the dev and test cycles. We have not gone to 6 yet. If you get it running in 6 can you let us know?
Thanks
– Alden
aldenMemberDavid,
You have done all the things to diagnose this. It sounds like the Y axis drive is not working. One question – is the Y current setting pot OK? If these pots get over torqued (moved beyond their 270 degree rotation) they fail.
In either case it sounds like a board replacement is in order. Please contact us at the synthetos email address to arrange.
– Alden
aldenMemberSorry, I messed this up when I merged into master last weekend. We have started posting the current hex files in the Downloads area
https://github.com/synthetos/TinyG/downloads
From now on this is where you should look for them – at least for the master branch.
-Alden
aldenMemberThanks for the update. This is looking really cool. You may be interested in the JSON work I’m doing. I am making another pass at the JSON libs to regularize the output. This should make machine parsing much simpler and more managable. All responses will come back in the same form, including parameter set and query, gcode lines, status reports, and system startup messages and warnings. It’s still in the github dev branch under active development right now. I’ve started documenting on the wiki:
– Alden
- This reply was modified 12 years, 2 months ago by alden.
September 2, 2012 at 6:52 am in reply to: G83 canned cycle, applicable to other canned cycles. #3455aldenMemberThanks for your interest
aldenMemberWe’ve noticed this as well. It looks like interference between the noisy spindle and the computer – in particular the USB port. What type of computer are you running? Riley had a similar issue with his Panther and things work fine on one machine (Mac) and poorly on another (Dell laptop). We are still trying to work out how to isolate this. The best solution is to make the spindle less noisy. To that end we are trying some capacitors and varistors for spike clamping. Do you have separate AC circuits you can run the computer and spindle on?
aldenMemberSome thoughts. Also, I’m going to move this to the github as an issue so it’s tracked better. See https://github.com/synthetos/TinyG/issues/25
I think you can get to this w/o a login, but you may need a github login to comment. Best to continue this discussion over there if you do that. Sorry, this forum and the github serve somewhat different purposes but do overlap.
First, machine (absolute) coordinates are implemented (G53), as are 6 work coordinate systems, G54, G55, G56, G57, G58 and G59. G92 offsets are also implemented as proper G92, G92.1, G92.2 and G92.3 as per Kramer (NIST RS274NGC-V3) If you remember where you read that machine coordinates are not available I’d appreciate a pointer. Sounds like the wiki has inconsistent data and I’d like to fix that. Otherwise I’ll just hunt for it. Time for a revision pass anyway.
You are actually calling for 2 things in your code: canned cycles (like G83), and subroutines, or O codes in LinuxCNC (EMC2) speak. See: http://linuxcnc.org/docs/html/gcode/o-code.html
Canned cycles (G81-G89 + G38.2 probes) are anticipated but to date the only thing that resembles a canned cycle is the homing cycle. Here’s what would have to happen in the code to add a new canned cycle (for when you get to looking at the code)
– Add the G code and its parameters in gcode_parser.c. In the case of G83 Q word would also have to be added – this is not already in the Gcode model. That would need to be added to the GcodeModel and GcodeInput structures in canonical_machine.h
– Next a canned cycle should be added as a canonical machining function in canonical_machine.c/.h. This should call the actual cycle that would probably be in its own file, something like cycle_g83peck_drill.c. You can look at cycle_homing.c for an example of how this might work.
– The controller in controller.c handles blocking and threading using a state machine as implemented in _controller_HSM() in controller.c. Essentially it starts the main loop at the lowest level of blocking (i.e. the highest priority routine) and continues down the list until a function would block. No actual blocking is allowed, so the function returns a “busy signal” (EAGAIN code). This causes the main loop to restart. For this to work the functions that would block need to be coded as continuations. Continuations are functions that are split into 2 parts – the part that gets called initially- which runs some init code and sets up some memory variables, then the continuation “callback” that gets called from the main loop. The cycles need to go into the right part of the main loop – in this case right under the homing callback. See the following for more details:
https://www.synthetos.com/wiki/index.php?title=Projects:TinyG-Module-Details#controller.c.2F.h
O codes (subroutines) are more complicated. I’ve thought about this for some time now but have not bitten the bullet on this. There are at least 3 new things that need to be added for this to work. (1) subroutines and conditionals, (2) parameters, and (3) expressions. See the EMC O code page for how they implemented this. I’ve been careful to not step on the characters needed for expressions, so they are still available for use in Gcode lines. Parameters are a challenge for an embedded system with limited memory. They are doable, but there won’e be 5999 of them – not enough memory. Some form of sparse mapping will be required. Hopefully I’ll be able to attack this at some point, but there are a lot of other things that should probably get done first. Just having canned cycles would be a help even if there were no subroutines.
- This reply was modified 12 years, 2 months ago by alden.
aldenMemberThanks for the really good comment. I’ll enter an issue on the github to change the homing order to Z first. I’ll also look into the the other points.
aldenMemberI do have some rattle on the Z axis at hugh speeds. I attributed this to the construction of the Z axis on the Shapeoko. It rattles. You can see this in my YouTube video (search on “TinyG Shapeoko”).
I don’t have these other issues with my motors, but I prefer to run them at at least 2x microstepping. I notice 1x is very noisy. This is true on almost any driver, not just TinyG (or grblshield).
It sounds like you may also have the Z max velocity set too high for your motors ($zvm). Try dropping it a bit at a time and see if you can get a full move with a G0. Ut may also help to play with the current setting when you do this. Be careful not to strip the pots by turning them too far. Then set $xfr to the same value.
aldenMemberIf you move the motor to a different motor channel (1,2 or 4) and set the parameters the same as they are in motor 3 do you get the same results?
ALso, what results do you get if you run the motor at 2 microsteps instead of 1?
aldenMemberThese look good. Can you explain what was happening in the third video? I could not tell. Some questions to try to diagnose this:
– How much torque was the movement in the 3rd video delivering? Can you stop the motor by hand? How hard is it to stop?
– Does the Z axis work better if you drop the Vmax from 1200 to (say) 1000 or 800?
– Do you get better results with a G1 F800 Z…?
– Is your motor a 200 step of 400 step motor? Your settings are for a 200 step motor.
– How hot does the Motor3 chip get (Z axis?). Do you have an IR thermometer, if not just feel it by touch – relative to the X and Y chips.
– What is your current pot set to. Say that 12:00 is dead center, 8:00 is off and 4:00 is full on.
aldenMemberUntil dual axis homing is supported with two homing switches the way to do it is the same as single axis homing.
Set the axis mapping (as you probably already have) to Motor1 = X, Motor2= Y, Motor3 = Z, Motor4 = Y.
Put a switch on each of the X, Y and Z axes. Typically this is at minimum X travel (far left), minimum Y travel (towards the front of the machine), and maximum Z travel (the top of the Z travel). Since any switch port will react if it is thrown, you can wire these to Xmin, Ymin, Zmax, or you could wire them all in parallel to any X, Y or Z switch (There is a bug in the A switches right now, so don’t use these).
To home, first make sure your Y axis moves freely and is not racked – i.e. it can’t be out-of-square so much that it won;t move. Try to square it the best you can by eye.
Then set up the homing parameters for the way you have your switches set. See instructions under Gcode Support / Homing on the wiki.
-
AuthorPosts