Could it be data error? I think axis 6 should be directly linked to the servo motor.
Posts by 4wheeled
-
-
4wheeled: what is it you actually want to do?
Discussing these Karel VM scheduling details is interesting, but perhaps not the most efficient way to go about achieving what your goal is.
Hi, we are trying to run the DPM and it looks like the looping problem causes DPM interruption because DPM needs offset input every ITP of 8msec.
-
What controller version are you running?
The R30iB+ offers a 4ms ITP. This is probably one of the biggest advancements of the controller versus previous versions. Before this version, the ITP had been 8ms for a long time. I think as far back as the RJ3. I couldn't attest to anything older than that. Although, I don't know if DPM can truly keep up. I can find out if you're interested.
Two other huge improvements of the R30iB+ controllers are:
1gig DRAM file storage. Yay we're getting late 90's PC performance, albeit this is more impressive since it's on a RTC.
The other is spline motion, although I've yet to test it. I have a specific application that I REALLY wish I could test this on. Some have told me though that karel path motion could work also. I don't want to hijack this thread, so if anyone has an opinion on this, please PM me or feel free to start a new topic. (Or PM me to let me know I should do it myself😏)
We are using the newest version which is the R30iB+. Yes, we are working on DPM and it has been a lot of problems as I stated above. Thanks for the help.
-
I assume the controller is still occasionally performing some lower-level functions that result in this instability. If consistency in your application is more important than raw polling rate, then it may be worth trying to add your own short wait that occurs every cycle, while still keeping the %delay at 0. This might give the system time to perform other operations without causing an unpredictable, longer cycle. Try increasing the length of this wait until the instability is gone or you are no longer cycling fast enough for your application.
Thank you Erik for the advice. This is excellent thinking. But it seems that the minimum time unit is 8msec. And the application that I'm running requires an 8msec cycle too. So I'm not sure I can add a short wait like 1msec, but maybe I will give it a try.
-
Interesting. It seems that there is always a matching short and long cycle so it probably averages out to the correct total time.
I think you are probably at the limits of what the controller will do. In my experience Fanuc controllers are very slow processing compared to a PLC or microcontroller.
Does your application require it to be this precise it is it just a curiosity of yours?
Yes that is very strange. And we also approached Fanuc Japan for support on this one but they said it was too fundamental an issue that they would not be able to support us at the moment.
The application we tried to run is the DPM, which is also lacking factory support. So maybe we will consider giving up Fanuc. The RSI from Kuka is much easier to run.
DPM requires an update rate of 8msec which seem to be the limit on this system.
-
Well, we thought the problem is solved, but it isn't. It just had an improvement, but when we taking longer data, the system still shows instability. So with %delay=0, the instability which occurs every 100ms or so is gone. But the problem shows up at a much less frequency, see the plots attached. It must be the system wonders around doing some extra stuffs. (The X axis is count and the Y scale is usec)
-
You might already know, but delays exist for a reason. At least this one.
It prevents the round-robin scheduling from not being able to suspend your task.
Runaway programs are much harder to deal with without some forced yielding every now and then.
It is actually quite easy to put a conditional break in the loop. So it will not become a problem of runaway.
-
Am I completely misinterpreting this section of the Karel manual, or is Fanuc outright saying there is an extra 8msec delay every 250ms (by default) on top of the actual scan cycle.
I'm not sure how often op is seeing this extra delay(the x-axis of his graph seems to imply it's more often than every 250ms)Ops graph shows the extra delay is happening every 96ms, but maybe his controller has a different default %Delay value or this is part of it? Please let me know if I'm being an idiot and not understanding the manual here though.Dear Erik,
Indeed, with %delay=0, the problem is gone. Thank you!
Jay
-
Thank you. This is very interesting. We will give it a try and report back.
Am I completely misinterpreting this section of the Karel manual, or is Fanuc outright saying there is an extra 8msec delay every 250ms (by default) on top of the actual scan cycle.
I'm not sure how often op is seeing this extra delay(the x-axis of his graph seems to imply it's more often than every 250ms)Ops graph shows the extra delay is happening every 96ms, but maybe his controller has a different default %Delay value or this is part of it? Please let me know if I'm being an idiot and not understanding the manual here though. -
Most Fanuc robots have an 8msec scan time. My guess is you are too close to that edge that occasionally you get an extra scan.
I wouldnt expect a delay function to be deterministic down to the exact msec.
What happens if you set delay to 10?
OK,I will try and report back. But I think if I do delay(10), I will still get 16msec according to the manual. The extra scan, if it is, happens very regularly.
-
Hi, I found a very strange thing with Karel looping.
So we tried a simple test loop with 8msec interval. The test code reports the time every loop. I was expecting a nice 16msec interval, but it turned out, it would do 8msec for about 6-7 times before it missed a cycle, see the plot at the attachment.
This is very strange. Is there anybody who also has similar experience?
Thanks,
Jay
PROGRAM ZKAREL
%ALPHABETIZE
%COMMENT = 'ZKAREL//r0b'
%NOLOCKGROUP
%NOPAUSE = COMMAND + TPENABLE + ERROR
TYPE
dpmm_t = STRUCTURE
shutdwn_req : BOOLEAN -- program abort requested status
ENDSTRUCTURE
CONST
LOG_PFIX = 'ZKAREL '
VAR
this_ : dpmm_t -- prog instance
stat_ : INTEGER
inputs : ARRAY[19] OF REAL
pos_log : FILE ---log
time_pos : INTEGER
ROUTINE handle_tp_data(this : dpmm_t;pos_log: FILE) : INTEGER FROM ZKAREL
BEGIN
stat_ = handle_tp_data(this_,pos_log);
END ZKAREL
ROUTINE handle_tp_data
VAR
stat__ : INTEGER
BEGIN
time_pos = 0;
inputs[1] = 1.0
OPEN FILE pos_log('RW','ud1:POS_log.txt')
WHILE ( DOUT[1] = OFF ) DO
CONNECT TIMER TO time_pos
WRITE pos_log(time_pos,inputs[1],CR)
DELAY(16)
ENDWHILE
lbl_hc_break::
CLOSE FILE pos_log
DISCONNECT TIMER time_pos
RETURN (-ABS(stat__))
END handle_tp_data
-
Wow, that's nice. Just did some search but there is not a lot of information out there about the R891. Is it possible for me to ask for a manual?
Most controllers run their Karel VMs at 125 hz and scan times have to be integer multiples of the period. 250 hz is possible with special options (probably those were what the engineer you talked to had in mind).
Whether the jitter on the scheduling running those condition handlers is 1 ms I cannot tell you. I would suggest to experiment with it. Karel does have access to a micro second clock.
If that is all acceptable to you, using Karel may work.
R891 though will make things much easier, as you can just configure some system variables and that's it. The system takes care of the rest. No Karel needed.
-
OK, I need to clarify. I don't need a 1kHz update rate, I could live with a 100Hz rate, which is a 10msec interval. But I need the timing to be accurate, to 1msec preferably.
OK, I will look up the R891 option. Thanks.
I'm also studying the relevant commands or settings and hoping these could provide me a stable timing:
$ SCR.$ cond_time
$ SCAN_TIME = n
heartbeat
delayHave anyone used these?
You won't get 1000 hz, but ask for option R891, the High-Speed Position Output.
Maximum frequency is 500 hz on iB+ controllers.
Gets you Cartesian pose and other data. But higher rates will probably reduce the data you can get out of the robot.
Another option would be to not use the robot, but use an external system which tracks the position of your scanning sensor. Even moderately priced laser scanners can do 1000 hz these days, but it will probably still be more expensive than R891.
CONDITION[n]:<WITH $SCAN_TIME = n>.
WHEN conditions DO actions
ENDCONDITION
-
Yes, you're right. I was quoted by a Fanuc engineer that the highest update rate is 4msec. So I will settle for 4ms. Yes, I'm searching for a Fanuc guru. Unfortunately most of the tech support engineers referred to me have more experience with robot application project rather than research subject.
So the research project I'm working on is on a 3D scanning application. So I need to know the position of the robot at moment of the scanning image acquisition. Apparently, the faster the update rate, the high rate of the scanning.
So thanks anyway for your comments.
Best,
Jay
I don't have any hard numbers, but I don't think its likely you can get updates at 1 msec. I would recommend trying to get access to a Fanuc guru (Someone beyond the tech support phone line). If you have a Fanuc sales person they may be able to give you a contact.
Who needs to know the robot position? Is it an external device such as a computer? Or is it a program running on the robot controller?
If its a computer, then Fanuc offers PCDK (PC Developer's Kit) which lets you write Visual Studio programs to access robot data such as position. I don't know the refresh rate.
Fanuc also offers software packages for streaming motion coordinates to the robot (Dynamic Path Modification or Motion Streaming). I have not used them. I assume that you can receive the current position as well as send desired positions.
-
Hi, we are working on a research project where we need to know the position of the robot while it is moving. The speed is in the range of 100-200mm/sec and we need to have a position precision better than 0.2mm.
That means we need a time measurement with a precision of 1msec. Is it possible with a M-10iD model that we have?
Many thanks,
Jay
-
You are correct, this option is implemented rarely. I've only used in on one job out of my entire career. You may have to contact Fanuc directly.
It would help if you posted what your settings and use case are. Also how are writing to the DPM system vars with your Karel program. You may have to write a software PID in there.
Did you end up messing with the $a1 and $a2 filtering variables?
No we haven't tried the $a1 & $a2 yet. We can try it after the holiday.
As for the settings, we followed this demo: https://github.com/gavanderhoorn/fanuc_dpm_mouse_demo
-
Happy Holidays, anyone still reading the tech forum?
It looks like very few people actually have much experience with DPM. But I still hoping someone with the real experiences could give us a hand.
Thanks and very much appreciated!
-
No, its the scale of input to the DPM schedule. It could be analog, or in your case a Karel var. In my case it was a group input sent from the PLC. My pitch correction wasn't responding quick enough, so I dropped the scale, and that solved the issue.
I double checked the manual, it looks like the SCALE would apply to the group digital input, the GI type. But in my case, it is the SV type, system variable from Karel. For the SV type, since the offset is already expressed through the system variable, I don't see how and why we need to apply a scale factor to it.
-
Haven't worked with DPM myself. But would like to read more about it. I did look on the internet for a DPM manual, but couldn't find any. It would be very kind if you could send me the manual please; i will PM you my e-mail adress.
The PDF is attached.
** PDF removed by Moderator - Please do not post Fanuc documentation **
-
You could change the scale of your channel inputs. Increasing it will cause the robot to respond slower.
Isn't the analog channel of which scale you can change?