Hello, I think its about Scale Factor ;
Display MoreHi guys
I'm starting to use the DPM resource and have some questions about it.
I'm testing the logic in RobotGuide and I have configurated the following for my application: Schedule 1, Group 1, Channel 3, Modal DPM, GI.
When I run the test program I simulate the GI[1] in the value of 50 (scale factor of 1) to path correction but the path deviates the value set in the max. value (100mm in this case). Shouldn't it correct the path with the GI value?
hello,
I had just started to testing out this DPM option and also encountered the exact same problem.
May i know if you had figure out what is the cause of this strange behaviour?
I think it's about the scale factor, like mentioned. Since GI's are 16-bit integers, if you use the integer value directly as DPM offset, you are stuck with an offset range of [-32768 .. 32767] with a precision of 1. With the scale factor you're able to redefine your range and precision to suit your application (and input).
I believe the DPM control has an internal scaling factor. If I recall correctly, when you set a scale factor of 75.0 in the DPM schedule settings, GI values are directly applied as offset 1:1.
Just to let you know, I've switched my simulations to use the 'SYSVAR' channel input type, as it gets rid of these scaling issues. So now I just directly write an offset for DPM schedule i and axis j to a system variable
$DPM_SCH[i].$GRP[1].$OFS[j].$INI_OFS
I think it's about the scale factor, like mentioned. Since GI's are 16-bit integers, if you use the integer value directly as DPM offset, you are stuck with an offset range of [-32768 .. 32767] with a precision of 1. With the scale factor you're able to redefine your range and precision to suit your application (and input).
I believe the DPM control has an internal scaling factor. If I recall correctly, when you set a scale factor of 75.0 in the DPM schedule settings, GI values are directly applied as offset 1:1.
Just to let you know, I've switched my simulations to use the 'SYSVAR' channel input type, as it gets rid of these scaling issues. So now I just directly write an offset for DPM schedule i and axis j to a system variable
$DPM_SCH[i].$GRP[1].$OFS[j].$INI_OFS
hi hoitzing thanks for the reply!
I had tested with 75.0 and sadly is still act very weirdly..
if thats the case, since im using a sensor value, do i just use BG logic to direct write value of GI into
$DPM_SCH[i].$GRP[1].$OFS[j].$INI_OFS, However roboguide does not allow me to write into the system variable, i think the parameter name is too long...
Hmm, seems like the 75.0 value is wrong then. If you want to continue with GROUP channel input you might want to play around with the value a bit to find what works.
As for the system variable; you're right it's too long for TP it seems.. I have been using KAREL to set the variable.
If KAREL is not an option for you I'd suggest diving into the scaling factor. Increase the maximum offset value (temporarily only) to allow the robot to always complete the DPM movement. Then you can compare the input offset (your GI) to the realized 'output' offset (the robot's movement) and go from there.
Keep in mind it's possible that FANUC uses the inverse of the scaling factor to rescale the input; i.e. check if the input scaling is done by multiplication or division by the scaling factor.
--- EDIT ---
Did some quick testing in roboguide and what I found was the following:
axis_offset = GI * 120/scale_factor
Display MoreHmm, seems like the 75.0 value is wrong then. If you want to continue with GROUP channel input you might want to play around with the value a bit to find what works.
As for the system variable; you're right it's too long for TP it seems.. I have been using KAREL to set the variable.
If KAREL is not an option for you I'd suggest diving into the scaling factor. Increase the maximum offset value (temporarily only) to allow the robot to always complete the DPM movement. Then you can compare the input offset (your GI) to the realized 'output' offset (the robot's movement) and go from there.
Keep in mind it's possible that FANUC uses the inverse of the scaling factor to rescale the input; i.e. check if the input scaling is done by multiplication or division by the scaling factor.
Checking back onto the manual, it appears FANUC uses division of the scaling factor to perform the scaling on the GI input. I guess I will do trial and error method to see if it works out or go for as you said, start looking into KAREL as alternative!
if I had use UFrame as the offset reference frame, keep on feeding values into GI will continuously pushing robot to move to the offset, so in that sense, the sensor reading value needs to be first zero it in relative to the distance of a surface, instead of taking the direct absolute reading of the sensor. does it make sense for this assumption ?
Yes you need to offset the sensor value (distance from robot to surface) with the target distance from the surface. So your DPM offset should be the difference between the sensor value and target distance (in opposite direction to negate the difference):
DPM_offset = -(sensor_value - target_distance) = target_distance - sensor_value
Yes you need to offset the sensor value (distance from robot to surface) with the target distance from the surface. So your DPM offset should be the difference between the sensor value and target distance (in opposite direction to negate the difference):
DPM_offset = -(sensor_value - target_distance) = target_distance - sensor_value
I had tried the KAREL option you had recommended to direct write the offset into the sysvar, and it does work! but I also noticed when i write a value at the offset it will direct become 0.00mm, in the manual it also says it does behave so..
The problem is now I'm now feeding a floating value (a simulated sensor value, so it will change based on LPOS) into this offset and the offset value in DPM is changing like crazy, so the robot z is changing violently too.
Is this normal? or am I missing out some settings?
One setting to keep in mind is the 'Offset accumulate' option:
I haven't really played around very much with this setting but it seems like you can go one of two ways:
1) Set to TRUE and keep track of what offsets you've already written; then for a new offset you only write the difference between previous and current offset.
2) Set to FALSE and simply write the offset that you require at that moment. In this case you'll probably need to make sure the "min/max offset/ITP" settings are big enough for the largest offset you're expecting
I've only simulated with option 1, and it works well; haven't really spent too much time on option 2 since I've tested with pretty large offsets which would give trouble with the maximum offset settings.
