Forum Replies Created
-
AuthorPosts
-
October 15, 2016 at 7:42 am in reply to: X and Z limit contacts non responsive and no SP control #9963
cmcgrath5035
ModeratorMy best guess is that something (some electrical event) has resulted in EEPROM corruption.
The tell tales for me are parameters that has ‘illogical’ values – values I doubt you would intentionally enter that are not part of any default set of values
Some that catch my eye are:
[xlv] x latch velocity 102 mm/min
[xlb] x latch backoff 5.004 mm
[xzb] x zero backoff 0.991 mm
[yjd] y junction deviation 0.0508 mm (larger is faster)
(not a complete list, just a hint as to what look like ‘odd’ values)My suggestion would be to reset your tinyG parameters to default, then re-enter values for your OX.
Steps
1. Make sure you have a parameter list backup – you will need to reenter most.
2. Use CP on Chrome or CoolTerm
3. Send the command $defa=1, which will reset tinyG to factory defaults (FW compiled in parameters)
3.5 After the $defa=1, have a look at the parameter list ($$), it will look nothing like your Ox setup, it is targeted toward board test.
4. Restart tinyG (reset button), connect with CP or CoolTerm
5. Re-enter all your unique parameters, one at a time, from the CoolTerm Command line or the CP Serial Port Console.
Make sure you are in mm mode (not inch) when entering parameters.
Avoid the CP parameter widget, enter one parameter at a time from the Command Line Interface (CLI) or Serial Port Console.
6. When you are done (and hopefully successful), re-create the document you posted above.
It is an excellent, human readable way to archive your settings should this event happen again.Hope that helps
ModeratorThanks for the info – all makes sense .
I have never used a Surface for anything, sort of assume it is IE based browsing (or Edge). Neither IE or Edge seem to run CP well (YRMV), likely due to JS issues.
Only other suggestion I have is a full parameter reset and reload – some users have experienced relatively silent parameter corruption. There are ‘hidden’ parameters also stored in EEPROM(parameters not intended for user tweak)that occasionally become corrupted.
Steps
1. Make sure you have a parameter list backup – you will need to reenter most.
2. Use CP on Chrome or CoolTerm
3. Send the command $defa=1, which will reset tinyG to factory defaults (FW compiled in parameters)
4. Restart tinyG (reset button), connect with CP or CoolTerm
5. Re-enter all your unique parameters, one at a time, from the CoolTerm Command line or the CP Serial Port Console.Hope that helps
ModeratorI pulled these from your PasteBin:
[1ma] m1 map to axis 0 [0=X,1=Y,2=Z…]
[1sa] m1 step angle 1.800 deg
[1tr] m1 travel per revolution 3.8900 mm
[2ma] m2 map to axis 1 [0=X,1=Y,2=Z…]
[2sa] m2 step angle 1.800 deg
[2tr] m2 travel per revolution 8.0800 mm
[2mi] m2 microsteps 8 [1,2,4,8]
[3ma] m3 map to axis 2 [0=X,1=Y,2=Z…]
[3sa] m3 step angle 1.800 deg
[3tr] m3 travel per revolution 8.0183 mm
[3mi] m3 microsteps 8 [1,2,4,8]
[4ma] m4 map to axis 0 [0=X,1=Y,2=Z…]
[4sa] m4 step angle 1.800 deg
[4tr] m4 travel per revolution 360.0000 mmTwo issues (maybe)
$4ma is set to X axis, as is $1ma. Most users would set $4ma=3 (or 4 or 5) if in fact motor 4 was unused. I am not sure what effect your settings might have.What sort of mechanical machine do you have (ShapeOko, Ox, ??). What I find strange is $1tr=3.89mm while $2tr=8.08mm. Most machines have the driveline (pulley, belts, etc) the same on X and Y. These are legitimate values, firmware wise, so I am just checking that they are intentional.
You ask “How do you know when the board is the problem and not the user?”
It is not easy to answer. Most of the time, if tinyG boots and the parameter set is correct, tinyG just works. That is why we ask about your settings.Some other ‘unusual settings’
X size larger than Y size – Legitimate, but not the way most folks configure typical machinesZmin limit switch – does it really exist? It is enabled
A frequent issue with limits not working is miswiring, e.g. wrong switch wired to port.
I’d suggest shutting off all limits and homing, concentrate on X and Y jogging, then add Z jogging motion (all in air first).
How do you communicate with your machine – CoolTerm, Chilipeppr, other?
October 9, 2016 at 10:18 pm in reply to: X and Z limit contacts non responsive and no SP control #9955ModeratorSorry, obviously missed your time line.
Typo on my part, the $$ command entered into the CP Command Window generates a Parameter list.
Those parameters reveal a lot about various aspects of your machine setup.
They are easiest to view in a cloud drive file rather than posted directly here in the forum tool.I suggest getting your machine up and running, jogging, running known good test Gcode, with limits turned off. Once the basics are well in hand, introduce homing, limits and advanced functionality.
-
This reply was modified 8 years, 1 month ago by
cmcgrath5035.
ModeratorAn up to date parameter dump to pastebin might help too.
ModeratorGood news, thanks for the info.
ModeratorDid you restore your parameters – they get reset by the FW update?
Sounds like limit switches are enabled and perhaps floating.
Post your Parameter set ($$ dumP to a cloud drive and post a URL here
October 3, 2016 at 6:10 am in reply to: X and Z limit contacts non responsive and no SP control #9941ModeratorCan you provide a parameter ist($$); copy to a cloud drive an provide a link.
When you say ‘shorting out”, you connecting to ground or +3v?
From you description, you know what to expect. Did your setup work, then stop?
ModeratorLooks to me like a potential driver device issue.
I suggest to connect to Customer Service atAttach a link to this post
ModeratorIf you search around a bit you will see folks recompiling G2 for higher performance Atmel devices, which might help in your quest for speed.
ModeratorThere are many users of DUE based G2 firmware.
I’d suggest reviewing the G2 wiki and also perhaps looking thru the Issues log on github.I have not seen a timeline for release of the “new board”, and if you are using external drivers anyway it may not be significantly more useful to you.
ModeratorLooking at your parameter set, you have $1sa=0.9 and $4sa = 1.8.
Is that a typo?
If the motors are the same, this pair of setting would have one moving twice as fast as the other.
$_sa=1.8 (200 setps per rev) is the much more common motor.ModeratorI have seen, but cannot dig out of the past, a description of stepper pulse rates for tinyG. It is not a topic important to most “standard” (what ever that is) users.
You might post an query here:My recollection is that it is limited by CPU resources, which would imply that tinyG2 (running on DUE) would be faster than tiny G, but in both cases (tinyG, G2) I don’t believe the pulse rate is user tweakable (easily, at least)
HTHModeratortinyG is not appropriate for Servo Motors – there is no accommodation in hardware or FW for the position feedback
ModeratorI’m not familiar with GRBL “sounds”, but what you describe might be due to differences in stepper power management strategy.
TinyyG can be configured to keep all motors energized when motion is active, to better hold position.
Review:It might help if you post your parameter ($$ dump) to a cloud drive and post a URL here.
-
This reply was modified 8 years, 1 month ago by
-
AuthorPosts
