Home › Forums › TinyG › TinyG Support › system won't movie once first alarm is cleared
Tagged: alarms homing
- This topic has 7 replies, 2 voices, and was last updated 7 years ago by cmcgrath5035.
-
AuthorPosts
-
November 6, 2017 at 4:47 pm #10673matthewdcMember
Where do i start?
I’ve been driving it without a problem but I keep encountering issues that don’t make sense:
-G54 offsets are all set to zero, status says homed and state is stopped, yet the position says it’s at zero even though I’m in the middle of the stage.
-then I get into states where it says it’s homed and at zero and state is stopped.
But it won’t move, even with a G28.2 command. No switches are depressed (like me at the moment)
Three axis homing takes over a minute so I’m using the Homed status to decide whether I need to rehome if I stop my control software then start it again (NO power off of the board)- This topic was modified 7 years ago by matthewdc. Reason: typo
November 6, 2017 at 6:34 pm #10675cmcgrath5035ModeratorStart here:
Using Chilipeppr, CNC.js, Coolterm?
Dump your parameters($$ command) to a cloud drive and post a URL. That answers a whole bunch of questions without me asking.November 9, 2017 at 9:51 pm #10679matthewdcMemberI’m using Labview, sometimes jumping to Coolterm.
One of the things that is messing me up is that although I’m in txt mode I sometimes get a json replay so my text matching gets messed up.
Here is my config fileconfig file
November 12, 2017 at 6:28 pm #10680cmcgrath5035ModeratorSorry, Forum tool does not always annount a reply comment and I forget to look.
You do have G55 and G56 offsets, but $$ agrees with you that G54s are 0.0.
Could be a Chilipeppr bug, or….This is a unique machine setup, X,Y,A1,A2.
Are A1 and A2 motors driving independent moving elements?I’d suggest you use $_pm=2, in-cycle. That way, motion on any axis will energize all motors, thereby holding position while other axes are moving.
Are X and Y belt drives or something else?
At $_tr=40 mm, I doubt they are screws.
I ask because some of your jerk values seem strange, but I doubt that is your issue.You have soft limits turned on, why?
What was the Alarm that was cleared?One of the things that is messing me up is that although I’m in txt mode I sometimes get a json replay so my text matching gets messed up
Is this when using Chilipeppr?
CP(SPJS) forces tinyG into JSON for a lot of transactions, because SPJS expects JSON in returnDescribe how Labview interfaces – does it interface to the Chilipeppr console, or what?
- This reply was modified 7 years ago by cmcgrath5035.
November 13, 2017 at 1:46 pm #10682matthewdcMember[You do have G55 and G56 offsets, but $$ agrees with you that G54s are 0.0.
Could be a Chilipeppr bug, or….]
I have the TinyG v8 board, latest firmware according to your website (.9?)
What is Chilipepper?[This is a unique machine setup, X,Y,A1,A2.
Are A1 and A2 motors driving independent moving elements?]
I must have left A2 hanging because I am only using X, Y, and A1.
The Y is mounted on the X stage but the rotary stage is independent. This is not a CNC rig; the setup is being used in a lab to automate image taking of a tooth (graduate student project).[I’d suggest you use $_pm=2, in-cycle. That way, motion on any axis will energize all motors, thereby holding position while other axes are moving.]
I can understand your suggestion although both my XY stages have acme screws and a minuscule load so it probably is not an issue. The rotary stage is heavily geared and horizontal so no issue with that.[Are X and Y belt drives or something else?
At $_tr=40 mm, I doubt they are screws.
I ask because some of your jerk values seem strange, but I doubt that is your issue.]
I might have played with the jerk trying to speed up or smooth out something but it is not important in this case. The movements are strictly travel only and I may have been trying to minimize the noise and/or travel time. Also not important.[You have soft limits turned on, why?
What was the Alarm that was cleared]
Somebody else is going to take over this project after I make a set of low-level subroutines for her. I’ve been trying to make the subroutines robust because she has no experience with motion control. After discovering the limit switches required a board reset which might screw up her situation, I decided the soft limits could be used to protect her from mistakes without bollixing up whatever she has running (she will be programming a Labview interface that she will then use for her graduate project. As typical for Labview, the development and usage are likely to be intermixed)
Her usage will be custom step-and-repeat sequences and probably make mistakes).
[One of the things that is messing me up is that although I’m in txt mode I sometimes get a json replay so my text matching gets messed up
Is this when using Chilipeppr?
CP(SPJS) forces tinyG into JSON for a lot of transactions, because SPJS expects JSON in return][Describe how Labview interfaces – does it interface to the Chilipeppr console, or what?]
Labview is talking directly through the serial port with $ and G commands.I’ve tried to simulate what is going on through Coolterm but it’s hard to do; the interface routines so stat checks and stuff. I’ve built a logger so that I can repeat exactly what the Labview code is doing up to the hangup but it’s still difficult to do. That is where I discovered a few problems of my own.
One of my difficulties with this board has been an unclear picture of the state of the board in different situations. Many commands that don’t expect a reply get one anyway, so I inserted a serial port read command to clear the buffer before sending a command to the board that DOES expect a command.
I experimented a little with the alarm and certainly am confused. The alarm does not seem to be system wide. After getting an alarm on X axis, a did a successful Y move and $stat says no alarm. If I try the X axis again even with a valid move, I get another alarm unless I use $clear. How does the flowchart actually look in this system with regards to alarms? My general approach has been to do a move, use $stat to see if the move was ok. If Alarmed, I send a message to the user interface. Something in my code is assuming something that is not true but after massive experimentation I have yet to figure out what.November 13, 2017 at 8:52 pm #10683cmcgrath5035ModeratorSorry, I was in mixed brain mode working with a Chilipeppr user in another forum. Chilipepper is a CAM overlay for managing tinyG. Implements aggressive buffer based Gcode delivery for speed and smoothness of motion.
So try to ignore those comments.Are you getting unexpected command responses, perhaps in json, or are they status reports?
Try turning off soft limits to see if they are affecting you code.
November 14, 2017 at 1:50 pm #10685matthewdcMemberThere is actually only one command that returns a json text but it is not a command that expects a reply so not a problem right now.
The only problem I really have right now IS the soft limits. In the end I can disable those but not happily so.
BTW, I fixed my homing problem as described in my original post; I was doing a text search in the reply for ‘homed’, not realizing the false reply was ‘not homed’.
- This reply was modified 7 years ago by matthewdc. Reason: removed redundant text
November 14, 2017 at 7:48 pm #10687cmcgrath5035ModeratorI have not used SL myself, so am just reading wiki and thinking I understand.
SL are only truly active IF (enabled) AND (axes homed).
I was suggesting turning off SL would get you machine moving again, assuming that perhaps, for whatever reason, SL was declaring a Soft Limit violation.
I’ll also comment that it is likely there has been little testing of limit violation on rotational axes. Few users implement A axis, fewer try to implement Limits on them.
Soft limits are triggered by violation on Min and Max Travel.
Perhaps reset Min to -355 and max to 355 deg as a test?
In reality, maybe, 0 and 360 degrees, being the same location and confusing logic? Just thinking out loud.- This reply was modified 7 years ago by cmcgrath5035.
-
AuthorPosts
- You must be logged in to reply to this topic.