BRX AXCONFIG Pseudo-bug

[Mike Nash]

BX-DM1E-36ED23

AXCONFIG of Axis 0 or 1

Setting Minimum Velocity to zero results in Error, Execution Mode shows "unconfigured" and I get

Axis disabled by .MasterEnable in AXFOLLOW @000000AA (AXFOLLOW at Axis1@39)

"Pseudo" because the instruction help says 10 is minimum, but the editor green lights a value of 0.

[Evilbeard]

So you got your new BRX? I got my stepper system and I've been playing around with Axis controls all day.

[franji1]

We will fix that.

[Mike Nash]

So you got your new BRX? I got my stepper system and I've been playing around with Axis controls all day.

It came in a last week, but I have been too busy to play with it. I just have power and Ethernet so far. I took forty forevers trying to copy the AXFOLLOW example from the help. The nicknames make that really difficult since I don't know what memory type they are.

It also griped about a retentive element in coil within a non-retentive stage. Dude! I copied it! 

Now I see that Axis0 set as rotary only allows 0-359 (360) but a linear follower keeps going in the same direction. I'm cool with the follower, but I think I need more than 360 points for the rotary. I only just tried that so I haven't dug into yet.

Whoops! The 0-359 changes to 0-3599 if I put in 3600, that threw me because it looked like hard limits. That'll work. So far so good. I am wanting to get a traverse even if I never use it.

What's your project?

[Evilbeard]

So you got your new BRX? I got my stepper system and I've been playing around with Axis controls all day.

It came in a last week, but I have been too busy to play with it. I just have power and Ethernet so far. I took forty forevers trying to copy the AXFOLLOW example from the help. The nicknames make that really difficult since I don't know what memory type they are.

It also griped about a retentive element in coil within a non-retentive stage. Dude! I copied it!  

Now I see that Axis0 set as rotary only allows 0-359 (360) but a linear follower keeps going in the same direction. I'm cool with the follower, but I think I need more than 360 points for the rotary. I only just tried that so I haven't dug into yet.

Whoops! The 0-359 changes to 0-3599 if I put in 3600, that threw me because it looked like hard limits. That'll work. So far so good. I am wanting to get a traverse even if I never use it.

What's your project?

Our machines have a system that edge guides on the web of the film and moves the carriage (where punches/registration eye/attachements are) and the front of the machine (where it is cut, stacked, and then conveyed) aligned with the film. Currently, it's using 1940's technology of 2 pressure switches, a machined "head" that detects the film edge. The carriage and stacker are moved physically by identical lead screws and a flexible shaft connecting them and an AC gearmotor. I'm looking at using a photoelectric sensor to sense the edge of the web, and then driving each lead screw with a stepper.

I at least have movement, I've just been toying around with the commands for now.

https://www.youtube.com/watch?v=cpFeQo0XkhM

[Mike Nash]

Good luck, I'll watch your video later.

In the meantime, the linear following the rotary looked great until I executed a relative move after which point it starts trying to follow the sawtooth of the rotary axis but with an offset which is ? I'm not sure what that tells me. Time to pack it in for the day.

[Evilbeard]

Good luck, I'll watch your video later.

In the meantime, the linear following the rotary looked great until I executed a relative move after which point it starts trying to follow the sawtooth of the rotary axis but with an offset which is ? I'm not sure what that tells me. Time to pack it in for the day.

It's a bit long, I didn't realize I set it to travel such a long distance. I'm simulating an 18 TPI leadscrew moving like 20" there. Also, pay no attention to my messy wires. I'm an animal.

[BobO]

In the meantime, the linear following the rotary looked great until I executed a relative move after which point it starts trying to follow the sawtooth of the rotary axis but with an offset which is ? I'm not sure what that tells me. Time to pack it in for the day.

The follower instructions are all following the source axis' absolute position. Not sure how that's gonna work with rotary.

[Mike Nash]

The follower instructions are all following the source axis' absolute position. Not sure how that's gonna work with rotary.

Which is what I figured, but until I commanded a relative position move it was a straight line in the follower as seen in trend view. I'll try it again but if it's not supposed to work I won't pursue it from that angle.

[Mike Nash]

Here's what I see (though the stalls on our VPN make it harder to see):

If Axis0 is the master and set for rotary 3600 counts.

And Axis1 is set to follow at a Gear Ratio of 1.0 .

When it starts following it is about 25 counts behind the master, steady state until the master rolls to zero. Axis1 now continues in the same direction and velocity but is now 3575 counts ahead of Axis0. At the next Axis0 rollover, Axis1 is now 3600+3600-25 counts ahead. This continues until I got tired of watching.

Set the Axis1 relative offset position to 0 and relative offset velocity to say 10,000 (Axis0 is 600) and one shot the Goto Offset Signal (GOS) on and now Axis1 locks in at the difference that existed at the one shot. If I now set the relative offset position to negative(whatever the difference is) and trigger the GOS again, Axis1 rapidly drops to match Axis0 and tracks with nearly no error(offset) afterwards.

So my takeaway is that AXFOLLOW has a quirky behavior potential until the first GOS.

BTW, this is almost exactly the example in the instruction help for AXFOLLOW except I used Axis0 and Axis1, so hopefully I didn't inflict any odd quirkiness of my own. I put it in it's own program called from $Main by RUN Axis1 (which is what I called the program. I hope that isn't an issue, but $Axis1 is the system stuff.)

[BobO]

Not quirky. Until the first offset adjustment, you haven't officially given me an offset velocity, I have no way to make corrections, so it simply runs a straight gear. You can do an offset with a value of zero, and it will correct to the reference point established when the instruction was enabled.

There was some debate about whether to make that behavior automatic at the enable, and the decision was to leave it as is.

[Mike Nash]

Not quirky. Until the first offset adjustment, you haven't officially given me an offset velocity, I have no way to make corrections, so it simply runs a straight gear. You can do an offset with a value of zero, and it will correct to the reference point established when the instruction was enabled.

There was some debate about whether to make that behavior automation, and the decision was to leave it as is.

How about "not well documented"?

From the help:

Goto Offset Signal - each time this Bit location transitions from OFF to ON the Follower Axis will attempt to move to the Relative Offset Position using the Relative Offset Velocity. The Axis does not have to be moving for this to take affect. This can be any Bit location.

Note: If the Relative Offset Position is reached the instruction will turn this Bit OFF. If this Bit stays ON it indicates the Follower Axis does not have the capacity to overtake the Master Axis. Fix this by making the Follower Axis more responsive by configuring it with higher Maximum Velocity or a faster Acceleration, or both.

The last sentence I took to mean it should track once the instruction was true, which it did do, until the master position changed waaay too fast. But it didn't even appear to try to correct at that point.

So anyway, so long as there's one pile anywhere, I'll step in it. I think I would have voted for an option to have auto, but it must have advantages to not trigger it yet (I think). Given enough relative offset velocity it certainly tries its best to follow that sawtooth. But rotary is definitely not what I need to be trying to use either way.

The help example also says the Gear Ratio is set to 2.5, but the instruction clearly shows 1.0 . I do try to read this stuff.

Edited to add: I'm really not trying to rag on you!

[BobO]

How about "not well documented"?

Let's say that the documentation is a work in process. Much of this functionality was developed very late in the process and was changing daily even later in the process, due to feedback from ADC. We'll see if we can improve in it a bit. Sorry for the confusion.

The last sentence I took to mean it should track once the instruction was true, which it did do, until the master position changed waaay too fast. But it didn't even appear to try to correct at that point.

Sounds like it is working correctly, but I can see how it would be interpreted as quirky.

As for the piles you manage to step in, we really should involve you with future beta programs!

[Mike Nash]

AXFOLLOW wasn't the function I needed anyway. AXGEAR works a treat it appears for a traverse. Take the master axis position (or encoder input) and create a sawtooth using MOD (Math %). That value is the input to a LERP which picks the appropriate Gear Ratio for AXGEAR based on spindle count in that profile and it just works. Funny how I needed a sawtooth, but it's only to pick the gear ratio as I go. The master is still a linear count.

Changing on the fly without any hiccups is sweet!

BTW, the AXGEAR example is where the 2.5 ratio came from in the AXFOLLOW example, (cut, paste, miss the edit.)

[Mike Nash]

I promise I don't go looking to break things as I WANT them to work.

I imagine I am coloring outside the lines, but this is the only issue I have seen with AXVEL. I was playing around with it and got to wondering how it would respond to the velocity setpoint getting yanked around (because that's how it goes) with S-Curve. It is way better than I ever managed to kludge together when a packaged one wasn't available. But then I stumbled upon one scenario (combination of settings and setpoint change at a particular point.) I am attaching a screenshot.

This occurs when the decel rate is maybe 15% or less than the accel rate. The less it is the more noticeable it gets. It is similar if the accel is 15% or less than the decel. And it shows up predominantly if the setpoint is changed after the S-Curve at start has finished and the setpoint will be before the velocity it has just passed, especially if it was heading toward a velocity much greater than current. (I don't even know what I just said.) Maybe that will explain the screenshot. I started at zero velocity with a setpoint of 5000 and then dropped the setpoint to 2000 around a velocity of 2300. Sorry, the minor tick marks are not on 100s. What I am seeing is an immediate reduction in velocity but after a point the velocity output jumps back onto the "preplanned" curve. I have not played with the S-Curve setting to see how that factors in.

I just saw the screenshot has the names covered for the trend.
Yellow is $Axis0.TargetVelocity
Green is $Axis0.CurrentVelocity

Maybe just a precautionary tale - Don't do what I do.