Forum Replies Created
-
AuthorPosts
-
March 24, 2013 at 9:01 pm in reply to: motor 3 (Z) stalling on shapeoko when sending program file via coolterm #3944aldenMember
SOunds like it. Let’s get a return going. Please contact us at the synthetos gmail address.
March 23, 2013 at 3:24 pm in reply to: motor 3 (Z) stalling on shapeoko when sending program file via coolterm #3937aldenMemberYour Z jerk might be too high. You have it set to 1,000,000,000. (1billion) I set my shapeoko Z to 50million. I’d try to get Z working with the following settings:
Run G21 first so all settings are in mm mode $3mi=2 set motor3 to 2 microsteps (assuming motor 3 is mapped to the Z axis $zvm=400 set max velocity to 400 mm/min. Shapeoko Z should be able to do 1000, but don't start there $zjm=10000000 10 million. Ramp up to about 50 million once you clear the lower numbers
Then ramp up slowly to $zvm=1000 and $zjm=50000000 (50 million)
I’m writing instructions on the wiki as we’ve seen this type of problem before – it’s usually a settings problem. Even if it’s not your issue the instructions might help. It also has some other things you might check if this doesn’t work.
https://github.com/synthetos/TinyG/wiki/Troubleshooting#z-axis-stalls-during-gcode-file
March 23, 2013 at 11:52 am in reply to: motor 3 (Z) stalling on shapeoko when sending program file via coolterm #3935aldenMemberYou might alos try dropping your Z jerk value and experimenting with motor 3 microsteps at 2 or even 1
aldenMemberGlad to hear you fund the problem, and sorry it’s board related. Let us know if you can manage this yourself or if you need help from us.
aldenMemberThanks. Jason was the original poster. I don’t know if he’s got it working yet. Here’s what I know. There was a problem prior to build 370.08 where the PWM channel was being initialized and interfering with the coolant LED. I disabled the PWM and spindle control RPM control to move this out of the way and the Coolant channel was unblocked. It tested out OK on v6 and v7 boards so I posted to edge (a bit belatedly). You were not able to get the M7,M8,M9 commands working. I retested with the edge tinyg.hex files from both the default directory (AVRStudio4 build) and Debug directory (AtmelStudio6.1 build). Both worked.
So I’m a bit baffled right now why you board isn’t functioning. You should get a power-on message that looks something like this:
{“r”:{“fb”:370.080,”fv”:0.950,”hv”:7.000,”id”:”9H3583-RMP”,”msg”:”Loading configs from EEPROM”,”f”:[1,15,0,8118]}}
{“r”:{“fb”:370.080,”fv”:0.950,”hv”:7.000,”id”:”9H3583-RMP”,”msg”:”SYSTEM READY”,”f”:[1,0,0,3609]}}
I’ll be out most of the weekend so testing is going to be hard. I like to get these kinds of things nailed, however, so any insight you gain is much appreciated.
–Alden
aldenMemberWeird. It’s working on mine. I wonder what’s different? If you send an email to the synthetos gmail dotcom address we can exchange info and get a chat or get online somehow and try to fix this.
March 22, 2013 at 10:22 pm in reply to: motor 3 (Z) stalling on shapeoko when sending program file via coolterm #3924aldenMemberSorry you are having problems. Some questions:
– Can you post the Gcode file you are running? What program generated the file?
– When you say you are running flow control – I just want to confirm that you have Xon/Xoff enabled in coolterm
– Does it fail in the same spot each time?
– From your settings it looks like you have homing switches in place. Does the system make it through the homing cycle OK? G28.2 x0 y0 z0?
Thx
–Alden
aldenMemberIt was working on v6 and v7, so I just checked it again. Still works. Are you running a v7 board? The hardware version is set for V7. Also, which tinyg.hex did you use?
aldenMemberOK. Back to the bench. Sorry for the inconvenience.
aldenMemberNo, it’s designed that way. The CW/CCW is persistent.
By way of explanation – if a motor is set to CW or CCW operation something has been electrically activated, possibly a relay of some sort. I figured it was better to leave the CW/CCW setting alone and independent of the ON/OFF setting. If someone has any ideas about why this is a good or bad practice I’d be very interested.
Thanks
–Alden
aldenMemberSorry, It should be up in edge now
aldenMemberI have a fix pushed to the edge branch as build 370.08 If you want to try it out and see what it does I’ll hold off pushing to master. You can use the tinyg.hex in either the default directory or the Debug dir. Either should work.
aldenMemberI found the problem. I also think it’s a v7 issue as well and is not limited to v6. The PWM/spindle code is not properly integrated and collides with the coolant bit. I will post an edge (and possibly master) push that fixes the issue. This should work for both v6 and v7.
Alden
aldenMemberJason,
Try setting the hardware version to the v6 board
$hv=6
Alden
March 21, 2013 at 6:24 am in reply to: Limit switches not working, config changes not being saved #3904aldenMemberThese items have been fixed in 370.07 currently on the master branch
– Fixed problem where settings entered in Inches mode are saved to EEPROM incorrectly
– Changed help text to agree with changes in 0.95 release
-
AuthorPosts