mcgyvr

More info.. Finally got my UPS in the mail so I hooked it up to that..It ran just fine 4 times through the code then boom again..
This time coolterm had finished sending the gcode and I was actually able to see an error Its all right here. Is it “telling” of something that the system shutdown error came then a movement then again ? Or how about a -0.000 velocity..? pulling at straws..

Note it did hit a limit switch (never should have been close but when it went psycho speed mode the y axis slammed into the non-homing side limit switch. It really seems like its still trying to execute the code but when the axis goes to full speed obviously tinyg would be lost as to where it really is.

Here is what I was able to get in coolterm..
tinyg [inch] ok>
qr:1
tinyg [inch] ok>
tinyg [inch] ok>
qr:1
tinyg [inch] ok>
qr:2
tinyg [inch] ok>
tinyg [inch] ok>
tinyg [inch] ok>
posx:6.675,posy:6.750,vel:-0.000
qr:3
posx:6.675,posy:6.750,vel:0.416
posx:6.684,posy:6.773,vel:41.623
posx:6.744,posy:6.924,vel:149.636
posx:6.858,posy:7.206,vel:199.584
posx:6.975,posy:7.500,vel:176.587
posx:7.053,posy:7.694,vel:81.582
posx:7.075,posy:7.749,vel:6.660
qr:4
qr:5
qr:7
posx:7.075,posy:7.750,vel:-0.000
qr:8
posx:7.075,posy:7.750,vel:0.416
posx:7.097,posy:7.738,vel:41.623
posx:7.228,posy:7.667,vel:149.636
posx:7.493,posy:7.524,vel:199.063
posx:7.783,posy:7.367,vel:200.000
posx:8.073,posy:7.211
posx:8.362,posy:7.054
posx:8.635,posy:6.899,vel:185.016
posx:8.853,posy:6.789,vel:100.000
posx:8.922,posy:6.752,vel:12.591
qr:9
qr:10
qr:12
posx:8.925,posy:6.750,vel:-0.000
qr:13
posx:8.925,posy:6.750,vel:0.416
posx:8.936,posy:6.777,vel:45.890
posx:8.994,posy:6.924,vel:149.636
posx:9.108,posy:7.206,vel:199.584
posx:9.225,posy:7.500,vel:176.587
posx:9.305,posy:7.700,vel:75.858
posx:9.325,posy:7.749,vel:6.660
qr:14
qr:15
qr:17
posx:9.325,posy:7.750,vel:-0.000
qr:18
{“er”:{“fb”:370.08,”st”:27,”msg”:”System shutdown”,”val”:1}}
posx:5.000,posy:8.000,vel:0.000,stat:3
qr:24
{“er”:{“fb”:370.08,”st”:27,”msg”:”System shutdown”,”val”:1}}

• This reply was modified 11 years, 4 months ago by mcgyvr.

Alden, (and Riley)
Thanks..
I know these types of problems are virtually impossible to “internet diagnose” so I really do appreciate any help you can provide.

Ok.. update.. Removed all the ; comments..problem still occurs, removed ALL comments..problems still occured.. Rolled back to the master build firmware and the skipping of G code lines is 100% gone.. HOWEVER I still have the problem that I talked about in another post with the stepper motors going to an “insane crazy” velocity.. WAY faster than what I have set as the velocity or feedrate maximum. It only happens on occasion and the only help I can give at this point is that it happens at the exact same time that (or a split second after) the android app finishes sending all the gcode to tinyg. (note its also happened with tgfx so its not just a Matt Stock app problem). At that time it “seems” to be attempting to finish the program but the stepper speed is so fast that its too much for my leadscrews/steppers to deal with so its a grinding noise,etc… Note that the android app has also stopped reporting velocity at that time but the positional DRO is still updating. I’ve had this exact same issue with tgfx.. Tomorrow I will run the gcode program multiple times from coolterm to see if it shows the same issue.

Really need some help to deal with this..

Note I’m only using simple X/Y axis G01 commands BUT I’m also using M8/M9 commands with G4 Px delays which I would expect very few if any other TinyG users are. So please keep that in mind when you think about a possible issue.
Again ..PLEASE help. I’m getting close to the edge of sanity now..

oh ok found out that Matts app was turning it off.. But does TgFx use/need it on?

FYI..
I am using NC limit/homing switches..
My issues so far have been
#1-blinking board mid job
#2-“supposed” tripped limit switch mid job but not even close to the switches.
When #2 has happened TgFx has popped up the “a limit switch has been triggered click here to reset.blah blah dialog.
BUT at that time it also went “crazy” in that the steppers went FULL speed (as in WAY faster than my max velocity is set for) and “sounded” like it was stripping all the threads in my leadscrews. The axis doesn’t move as speeds that fast cause my leadscrews to bind (for lack of a better term) but I just don’t know why it would go into that “crazy..way over max velocity speed cycle”

I don’t have a spindle to attribute noise too but rather a pneumatic cylinder that is triggered with the coolant pin.. But its running to a SSR and I have flyback diodes across the solenoid valves. I am powering the solenoids from the same 24V supply as TinyG uses though and am going to try to separate it on its own 24V supply.. However seeing as the gcode runs perfectly with coolterm Xon and I’m not seeing those issues I suspect its more of a bug somewhere vs a noise issue.

I do have shielded limit switch wiring (grounded shield at tinyG) and NC switches and have placed a .1uF cap across each switch line. But the problems still occur.. But only when running TgFx or Matt Stocks android app
And I did notice $ex was set to 0 in the tinyG config by default.. I now have it at 1 and will try again..
I assume that its ok to have $ex=1 when using TgFx or the android app??? right?

• This reply was modified 11 years, 4 months ago by mcgyvr.