RobotStudio event

Synchronizing rapid execution

Hello, 

I'm wondering if anybody has a suggestion for how I can improve the synchronization of my program, either through rapid or the controller configuration. The process is a additive-printing sequence, where the dispense-rate is varying along the path (such as decreasing around a corner). We've noticed that the dispense-rate is a few Robtargets ahead of the real TCP position, indicating that the process is looking ahead and calculating the upcoming dispense-rate too early. Our paths are usually made up of many smaller segments (2-5mm) and our velocity is usually around 30-120 mm/s. 

I know that using a fine-point zonedata can help with this, but unfortunately for a smooth printing motion it is important to avoid the stop/start motion. Perhaps there is something I'm missing in the motion_planner (MOC.cfg) which can give more precise execution, or in the movement commands within the rapid program.

Some motion planner parameters that may be relevant:
Path resolution = 1
Queue time = 0.2903
Use additional interp. object batch = 1
Prefetch time = 0.1 

Number of Internal Event Objects = 500

Thanks in advance for any help or suggestions!
I am using a IRB6400 with an IRC5 controller, running on RobotWare 6.08. 

Answers

  • But are you using Dispenseware?
    Lee Justice
  • But are you using Dispenseware?

    No we aren't using the Dispenseware Add-in, does this have some functionality which improves the program synchronization? 
  • In my opinion, yes.  It will come with features for gun on, off and you can set up an analog signal for tcp velocity/dispense rate, so to speak.  The controller as you have it will always read ahead in there are not fine points.  I have to ask also, you said something about the calculations are ahead of the motion.  Can you put a sample of that code here for us to see?  Might be able to help some more.  Are you using Trigg instructions already?  Dispenseware is based on that technology.  If you do get the dispenseware and even with the trigg you will want to look at event preset time.  A lot of people don't get that right.
    Lee Justice
  • Hi @lemster68, I want to get back to this old topic. Jay is an old collegue and I took over our printing development. The problem stated above is never fully solved since it was only visible in experimental way of printing. I am now looking again into this problem since we are printing way faster then in 2019.
    Basicly we update our rpm of the motor (mu200) by calling an interrupt when our ao_tcp_speed changes. The trap does an IndCMove to update our rpms. When printing 150mm/s the program crashes due to too many interrupts. Making the treshold lower, decreases our quality.
    While browsing the forum I found this topic.
    I am now working on getting an Analog output with triggspeed. But what is the best way to implement this signal into spinning of our mu200? 

  • Do you have multitasking?
    Lee Justice
  • Yes we do have multitasking. First I had the idea to make separate motiotask with small proc updating the mu200
  • That might be doable.  I need to ask about your interrupt that you mentioned.  Did you use ISleep or IDelete in the interrupt?
    Lee Justice
  • Yes we use sleep to sleep the interrupt of the top change
  • OK, good.
    Lee Justice
  • I tried to understand how dispenseware (we have that installed) controlls actuators but I did not really find how that works.
  • Do you need the manual?
    Lee Justice
  • Correct me if I am wrong but I was not really able to find anything about connecting the dispensing signals to hardware
  • When dispenseware is installed, the necessary signals are included, mapped to a sim board.  All that you need to do is remap the signals that you need to the actual physically connected signals.
    Lee Justice
  • Thanks, I know that dispense ware generates different signals. But for me it is not clear how I can spin the MU200 with these signals. Right now we used IndCmove but this is not suffiecient since our flow needs to adapt quite often. 
    Is there a way to directly control a mu200 by signals?
  • I thought that was the way you might be going when you mentioned setting up another motion task.  May I ask what is the minimum rpm and max that you require from that motor?
    Lee Justice
  • I figured we have multitasking but not multimove...
    Between 0 and 85 rpm
  • Oh.  I am guessing that you are using ISignalAO for interrupt.  Is that correct?  Could you maybe use a timed interrupt?
    Lee Justice
  • We do use ISignalAO. I tried to increase the delta but it decreased our print quality. The fastest timed interrupt allowed by RS is 0.1 which is also visible in our print quality. There is too little material when accelerating because it is not updating quick enough 
  • That is where dispenseware can help you, it have equipment lag times which you can adjust.  However, it is mostly used with a stand alone dispense unit, which the robot controls.  It sounds like you could benefit from taking away the MU200 from the robot and add a drive controller to it.  In this sense, you are creating a home made dispense unit.  There was also an integrated dispense pak that maybe you could transform your setup into.  Today it seems that it is called Integrated Dispensing Function Package.
    Lee Justice
  • What if you go the other way and have coordinated motion with the MU200?