Forum Replies Created
-
AuthorPosts
-
cmcgrath5035
ModeratorI like you build solution – recycling a desktop case to hold all the electronics.
Have a look at this:
On the left is a current set of parameters I am using, on the right are yours.
Big differences (Me vs. You): NEMA 17 vs NEMA 23, X and Z sizes, No Limit SW vs Limits and Homing, XYYrZ setup vs. XYZ(A not used) setupOther differences:
$ja=100000 vs $ja=2000000 You are using the recommended value, I am not and I don’t recall if this was intentional on my part. You machine corners faster than mine, should not be an issue here.$ex=1 vs $ex=2 I use Chilipeppr a lot, SPJS mamages flow control, I don’t think there is an issue here.
No switches vs Switches and soft limits enabled
— Because I have switches turned off, I don’t pay much attention to homing related parameters. The setting you have look sane to me.Videos
1. I noticed that the time tinyG reset, on the initial Y move, it was before any funny noises occurred
2. If I understood your dialog correctly, all the moves you show are the results of homing commands from Chilipeppr.First Z, then X, then Y.
3. I wonder if the link between CP and tinyG is getting confused by the tinyG reset. When CP starts up, it sends a sequence of initialization commands to tinyG, to ensure that both ends are ‘in sync’.
3A. To see if this ‘out of sync’ is an issue, any time you see tinyG reset, you could disconnect, then reconnect the SPJS using the icon on the SPJS widget. Reconnecting to tinyG would resend the start-up sequence.So, what is causing tinyG to reset?
Suggestion 1: Set a zero point somewhere well away from Home; move your gantry by hand, then Set Zero. The issue commands in the Serial console to move the gantry toward home, something like G0 X-200 then G0 Y-300 (premeasure so as not to bang into your rails). Do these moves also trigger resets and funky noises?
Suggestion 2: If you still get bad behavior on Suggestion 1 test, turn off all limit switches($xsn=$ysn=$zsx=0) and retry. This is a noise test, but noise should halt tinyG, not reset it so I am doubtful this is issue.
Suggestion 2: Turn off Soft Limits, set $sl=0. Then try to rehome.
(If Suggestion 1 test OK && Suggestion 3 test OK, perhaps an issue (bug) in Soft Limit handling).
ALso – what version of SPJS are you running? Most current is 1.80
ModeratorHmmm, I carefully reread your initial posting.
I suggest you carefully read the Wiki item I mention above.
By tinyG convention, the Zaxis home, if you have one, is at the top of travel, maximum + travel.
Sending G28.2 Z0 or G28.2 z50 both initiate homeing cycle to find Zmax(home) switch. The value (0 or 50 in this case) does not matter but there needs to be something(“G28.2 Z” will fail)
So, to be clear, G28.2 Z0 will move in a positive direction until the home switch is detected.The Z value at home will be a value, relative to where you set zero last, not necessarily Z=0 or Z=50.Chilipeppr Jogging: What OS are you running CP on, and what browser?
Is your Keyboard set to lang=English or perhaps lang=French?
Frequently, languages other than English do not get well tested.
As an experiment, set your keyboard to English and see if that corrects the arrow key jogging issue.ModeratorYou are in the right place.
Very strange.Just curious, have you reviewed the wiki items on Homing and Limits?
This behavior:
But when i use chilipeppr, if I click on the “+” for z axis its moving down and – it’s moving down,
Is hard to understand.
When in Chilipeppr, When you click on the Jog Z+ and Jog Z- in the Axis widget, watch the Serial Port Console widget display (lower left of screen).
You should see G0 Z__ commands heading out the Serial Port.
What do you see?As a general statement, anything that works from CoolTerm should also work by typing the same commands into the Serial Port Console command interface.
Is that true for you?What fw build are you running ion your tinyG? Most current is 440.14.
FYI, firmware version (0.97) does not mean a whole lot, it is the FW build ($fb) that is more important.ModeratorIf I re-read the thread correctly, when you swapped the drivers by changing settings, March 14 Step 2, the issue stays with the axis that has two motors.
I am wondering if your PowerSupply (24V) might be defective or for some reason going into premature current limiting. Wild fluctuations on 24V could explain the tinyG resets as well, perhaps delayed a bit by the filter capacitors on the 3.3V rail.
Because there are two motors on the Y axis, 2x the current will be required whether you drive the two motors from one driver, as you have been, or connect to 2 drivers (Y and Yrev).Do you have a Dig MultiMeter available? If so, try to monitor a Vmot point on tinyG, such as the fan voltage selector pin block. That measurement would include power supply cabling ad connectors. That would be J12 on this schematic page
It might also be helpful if you post your tinyG parameters to a file for review. See
ModeratorHmmm, here is the schematic page
Should we assume you connected input power with reverse polarity?
I would worry about C2, and the power converters U7 and U8.
Do you have an ohmmeter?.
Still have continuity between the power jack + and the U7 and U8 pins?
There could be hidden trace burnout.If you have a small (self current limiting) 12V wall wart around, you could try powering the board from that and see with a voltmeter if there is any life in U7 and U8.
Unless you are really good at SMT board repair, I wouldn’t waste a lot of time on it.
ModeratorIf the filtered PWM output is 3.3V max, won’t the Super-PID be limited as to Max RPM output?
Or is there a second calibration on Super-PID that translates 3.3V to mean max RPM?ModeratorSomeone recently had a similar situation, reported back later that he found set screws has loosened on pulleys, just enough that shaft could slip between nicks from the set screw cup. Worth a check I suppose. His was a NEMA23 machine as well, IIRC.
7% seems like a rather large error, I would agree.
And variation is worse than fixed (static) error.
Same error in X and Y?I assume your fw change was from 435.02 to 440.14 ?
I recently updated my NEMA 17 machine ($xtr=36.54) and have run several jobs that seemed OK, but did not get out a ruler and check; I’ll do that.report – I just Zeroed my machine at one end and made 5 sequential 100mm move in Y. based on quick measure with Scale screwed to side rail( not as accurate as yours, for sure),accuracy of each move good to at least 0.5% with each move and overall.Then G0 Y0, then G0 Y500; no observable error.
If you make a slower move, see same error? Perhaps too much jerk?
I am running with $yvm=16000 and $yjm = 5000I am running with $xpm (power mgt) =3 and $mt=10 sec
ModeratorHmmm , on my controller, the red LED is on whenever the Input (48V in my case) is on.
Sounds like controller, I agree.ModeratorInteresting, I have what looks to be the same Controller, purchased perhaps 6 months ago. At the time, the PWM input spec was 5V to 12V, I believe.
When you say “motor works fine”, do you mean motor directly connected to DC source, or motor connected to controller, and speed of motor controlled by controller POT?
Start first with Motor – Controller connection in POT mode, to ensure basic connections and controller functionality. Then move the jumper to external mode and connect tinyG PWM signal.Here is a summary of a PWM test I ran back in January, note that I buffered my 3.3V PWM logic up to 5V.
You can run the PWM from the command line (CoolTerm, ChiliPepper), the Gantry does not need to be in motion.
What are your PWM Parameters (enter $p1 from Command Line)?
ModeratorFirst I have seen of Super-PID.
My read of the instructions is that SuperPID will turn the PWM output back into s DC voltage, mimicking the wiper on the POT.
Buffer your tinyG PWM 3.3v Output to 5V and your should be good.
You might find this useful for calibrating once you are done:
ModeratortinyG2 is a port of the tinyG firmware to hardware platforms based on newer ARM based micro-controllers. Wandering the G2 WiKi might help:
G2 runs on the Arduino DUE, which has no drivers on board. G2 can be used with a Gshield for three driver applications and there are 4 driver shields available as well.
tinyGv9 is a 4 driver plus ARM uC hardware platform that at the moment is testing only. No availability date has been discussed.
If you want to ride the bleeding edge now, you are best off with a DUE and shield of your choice.
ModeratorUSB cables have been know to become intermittent in this environment, a lot more plugging and unplugging typically going on.
I suggest to move your tinyG up to current Edge, fw 440.14.Many bug fixes since 435.10, and power management fully implemented see:
ModeratorRural
By Edge your mean 440.14? Good Move.
Chilipepper probably not compatible with anything < 435.xxModeratorHere is a link to How-To:
Feedback appreciated.
It has run from Linux and MacOS so far.
Both Kevin (configuretinyG) and I have had an occasional failure, indicated by a timeout while waiting for the tinyG write response. Restarting the SPJS has cleared it, but it is not clear of that masks something or clears an issue.
ModeratorJim
Are you a Chilipeppr user?I have a beta widget there that will save parameters to a PC file and restore parameters.from a PC file.
-
AuthorPosts
