matthewdc

[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.

thanks for your reply cmcgrath5035

For homing, right now I have fallen back to simply delaying long enough for the stages to finish before using the $home. It seems like I discovered I will get a ‘Homed’ reply but I still haven’t worked out how that happened.
Is this the only way to monitor homing progress?
I also noticed that even if I home just one stage that $home (or $hom) will say ‘homed’ even though the other two stages haven’t been homed yet.

The reason I wanted to monitor the homing switch in particular is because I can use that to switch directions of the homing move, depending on the initial value of the switch. (the homing signal from this rotary stage is high for half of the range and low for the other half). Otherwise homing may take as much as 359 degrees to find the homing spot.

As for Labview, I’m using the USB port serial protocol to simply pass ascii (text mode, not JSON) that I’m used to using with other stages/controllers. I query the serial port for how much in the buffer and read that out. I thought that handshaking may be throttling the data being sent but when I changed it to ‘no flow control’ in labview it made no difference. Perhaps I need to do the same on the tinyg side?
I see that Coolterm receives the whole list of data (for $hom) but maybe there is some back-and-forth in the background I’m not aware of.

Serial settings: 115200 8N1, handshaking set to both XON/XOFF and RTS/DCD(?) on both TinyG and the Labview serial port.

• This reply was modified 7 years ago by matthewdc.

crapola, where is my brain?
I meant mode 1. It’s all working now! Sorry about the confusion.
thanks

wrong link? let’s try again here