Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: Mike Nash on April 12, 2017, 11:14:48 AM
-
Once again playing with the traverse idea. It looks pretty good at lower input frequencies, but gets wonky once the master gets above "relatively slow". Hopefully I am setting something incorrectly. The gear ratio is changed based on the master count (Axis0 AXVEL) from a MATH mod (%) converting it to a repeating sawtooth which is then the input of a LERP that sets the ratio to 0,1,0,-1,0 based on the position on the sawtooth. I take the LERP output and give it a scale factor, in the case I have attached the trend for that is 0.5 so I will have the follower at 0,0.5,0,-0.5,0 gear ratio.
At up to 8000 Hertz on the master, the slave follows pretty reliably. There are slight variations from the ideal stopping point, but not a lot. At 12KHz, this all goes to pot as it seemingly randomly decides to bobble around 3-4KHz instead of 6Khz. These spots vary based on what parameters I put in for the AXGEAR accel and decel.
The program is very minimal, the Axis1_Gear program is always run from Main. I'm using stages. I don't see anywhere I have much tweaking ability. I can hear the BX whine with the frequencies it is outputting and it gets rough where it looks rough on the trend. I only have trend updating status, nothing else, but I didn't see a difference. I tried upping the timeslice for Axis1_Gear from 100uS to 1000uS and saw no difference (didn't think I would but?)
So what's going on and how can I fix it?
-
I just noticed something else. Normally the $Axis1.MstSlvCoordError shows -2 to 2, but when the output gets confused it is showing around 40-60 positive or negative. I know it has to be more than that when it is 2-3KHz less than it should be. Is it not seeing the Axis0 frequency properly? I don't have any real world I/O except Servo step and direction,Position Clear, and Servo On outputs. The servo isn't even powered at the moment.
-
Yuk. Will check shortly.
-
Thanks. This is not a "real" project at the moment, I just got a chance to pursue this some more. This most likely WILL happen at some point based on past requests.
BTW, I substituted Axis2 virtual for Axis 0 and it still looks the same except the jitter seems to be less than before when it is wonky.
-
It's working as expected for me.
Are you changing the gear ratio on the fly?
-
I can dupe your picture somewhat by reversing gear ratio sign.
What are you expecting it to do while reversing gear ratio?
-
Hang on...digging some more.
-
I can dupe your picture somewhat by reversing gear ratio sign.
What are you expecting it to do while reversing gear ratio?
Axis1 needs to control the position of a guide driven by a screw, so linear positioning, reciprocal motion. I need a gear ratio of -1*(MyScaleFactor) to return the guide to the start position. This looks to work fine at lower frequencies. I am still not sure whether the master or slave frequency is the biggest problem. The failure to attain expected output frequency may happen either on the positive velocity or the negative, or both. It looks random to me. There are also huge transients on output frequency at some of the gear ratio transistions.
Yes, the gear ratio pops from 0.0 to 1.0 to 0.0 to -1.0 to 0.0 in one cycle if MyScaleFactor=1.0.. This repeats at the start of the next sawtooth. The master the AXGEAR is following does not sawtooth. The sawtooth is generated simply for me to "look up" the position and set the proper AXGEAR gear_ratio.
I tried gradual gear ratio changes, but I think there is a tendency to lose a pulse at times when the gear ratio is changed. Reducing the accel/decel rates was no go either. It pretty much works like I want except when it gets lost at the gear ratio change.
-
It doesn't seem to be doing it. I have done some work in that code, including fixing the previous bug you reported, so it's possible it is working right now.
If you want to post something for me to run, I'm happy to test with the current bits.
-
I can dupe it.
-
I'm sorry.
I really do want it to work and I am not out looking for problems. I promise.
-
I'm sorry.
I really do want it to work and I am not out looking for problems. I promise.
Nothing to be sorry for. Your 'skill' puts you at the top of my list for future beta programs.
Some people just approach things differently than others. We have some of those working here at Host. One in particular spent part of his career in different design assurance teams. He would probably give you a run for most weird stuff found, but he's not doing that kind of work at Host.
-
It first glance it looks like the re-normalization process (that happens after a ratio change) appears to be hung due to the extreme change. There is a bit of fuzzy logic in that, and your fuzz may be outside the fuzz I allowed. Not excited about it...that process has been the subject of several bug fixes.
-
I'm not sure what to do. As suspected, it is in the re-normalization. I made a tweak, which made it somewhat better, but is now causing the issue it was seeking to mitigate to begin with.
The issue is that when you make a big change to the gear ratio, there is a window of time where the slaved axis is falling behind relative to the master, due to his velocity not yet being at speed. This causes an overshoot. In an effort to minimize the overshoot, we wait for the slave velocity to settle at the new target before finalizing the re-normalization. the dramatic change you are making is well outside the design intent of this function, and I'm not sure I have a good answer.
Is AXFOLLOW not an option?
-
I'll have to go find the thread, but AXFOLLOW appeared to be even less suitable. You may recall I have been seeking a solution for traverse winding for quite awhile.
I don't get to control the winding spindle speed, but I need to precisely move either the whole winding spindle side to side, or move a guide side to side as the spindle rotates. The lay accuracy can vary from no real accuracy required, to trying to lay a product (lets say ribbon, but it could be anything) down with a very, very precise gap between the edges. Then pause for a wrap or start back immediately.
I could probably handle an accel/decel curve at the pause/reversal, but the AXGEAR looked like it started losing track of master counts which was making the follower position move outside of it's prescribed travel limits.
I am certainly open to suggestions for alternatives and I will go find the AXFOLLOW issue now.
-
The AXFOLLOW is here: http://forum.hosteng.com/index.php/topic,1978.0.html
but I admit to not remembering exactly why I didn't think it was going to work well. After I found AXGEAR looked good, I got really busy and haven't had to time to play with it much since. I'll try it again.
-
I could probably handle an accel/decel curve at the pause/reversal, but the AXGEAR looked like it started losing track of master counts which was making the follower position move outside of it's prescribed travel limits.
Any change to the gear ratio can do that. It's inherent to changing the gear ratio. We do things to mitigate it, but that's what you're bumping into. AXGEAR is fundamentally a velocity relationship. It's built on a function that uses position, which is what the re-normalization process is designed to work around.
AXFOLLOW is position-based. That may not help you either, but it doesn't lose position but neither can it change gear ratio.
I can't help by think you might need a combination of these instructions. Rather than yanking the ratio around, explicitly build the behavior with states, maybe a combination of AXCAM and some moves.
At the very least you are outside the design intent. That limits my options.