Jump to content
OMRON Forums

position monitor


JeffB

Recommended Posts

I want to use a polygon to detect if I’m too close to a wall. I’ve written the code in C on Windows and it works well (24 ns per check in debug mode). I have a few questions about porting it to PMAC C code:

1. I have some constant arrays in memory, around 5 MB in total. I assume this won’t pose any issue.

2. I could make an order of magnitude faster but I would need a 50 MB lookup table.

3. What size integer is fastest to work with (e.g. 32 bit int)?

4. When the plc detects the robot is too close to a wall I plan to servo off the motor. The motors have a brake function so servo off should stop the motor, which in turn should stop all the motors in the coordinate system.

Link to comment
Share on other sites

  • Replies 4
  • Created
  • Last Reply

Top Posters In This Topic

Your C-code should run as-is on Power PMAC as a background Linux program.

 

1. I have some constant arrays in memory, around 5 MB in total. I assume this won’t pose any issue.

No - it should not.

 

2. I could make an order of magnitude faster but I would need a 50 MB lookup table.

You should be able to allocate all available free memory in PMAC.

 

3. What size integer is fastest to work with (e.g. 32 bit int)?

A C “int” should be very fast.

 

4. When the plc detects the robot is too close to a wall I plan to servo off the motor. The motors have a brake function so servo off should stop the motor, which in turn should stop all the motors in the coordinate system.

The Power PMAC C-API has a number of motor/servo with brake functions, as in:

int BrakeEnable (int n): Disables amplifier for motor n and then if defined enables brake after a delay

void DkillCoord (int n): Kills all motors in coordinate system n and then if defined enables the brakes after a delay

Link to comment
Share on other sites

So better as a background program than CfromScript? I couldn't get CfromScript to compile on the brick so used a background program but was thinking of switching when I get the real hardware tomorrow.

 

DkillCoord sounds like it fits the bill.

 

Thanks

Link to comment
Share on other sites

  • 1 year later...

A few issues with your Question #4:

 

I'm afraid the quick description of the DkillCoord() function is incorrect (the description of the actual Script DKILL command in the Software Reference Manual is correct). The DKILL function enables the brake first, then disables the servo after a delay. It’s meant for a controlled shutdown when you are already stopped, and you want the brake to fully engage before disabling the servo, so there is no motion on disabling. It is generally not appropriate to use when moving.

 

I think a more appropriate function to use is AbortDkillCoord(), which implements the Script ADISABLE command. This implements an ABORT command followed by delayed kill for all motors in the coordinate system. The abort does a controlled closed-loop deceleration, bringing the motors to a stop faster than a kill would (and so in a shorter distance), and once stopped, the brakes can safely be enabled before the servos are disabled.

 

Taking a step back, I don't see why you would need to disable at all. If I read you correctly, you are implementing a sophisticated software overtravel limit function. In our built-in software overtravel limit function, we always simply use the "abort" function for a controlled closed-loop deceleration to stop. We do not subsequently disable the servos, as there is generally no need to do so. Recovery is substantially quicker if you leave the motors in the enabled closed-loop zero-velocity state. This can be implemented with the AbortCoord() function.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.

×
×
  • Create New...