Synchronizing rapid execution

jay_c

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. 

lemster68

But are you using Dispenseware?

jay_c

But are you using Dispenseware?

No we aren't using the Dispenseware Add-in, does this have some functionality which improves the program synchronization? 

lemster68

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.

m_stroober

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? 

lemster68

Do you have multitasking?

m_stroober

Yes we do have multitasking. First I had the idea to make separate motiotask with small proc updating the mu200

lemster68

That might be doable.  I need to ask about your interrupt that you mentioned.  Did you use ISleep or IDelete in the interrupt?

m_stroober

Yes we use sleep to sleep the interrupt of the top change

lemster68

OK, good.

m_stroober

I tried to understand how dispenseware (we have that installed) controlls actuators but I did not really find how that works.

lemster68

Do you need the manual?

m_stroober

Correct me if I am wrong but I was not really able to find anything about connecting the dispensing signals to hardware

lemster68

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.

m_stroober

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?

lemster68

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?

m_stroober

I figured we have multitasking but not multimove...
Between 0 and 85 rpm

lemster68

Oh.  I am guessing that you are using ISignalAO for interrupt.  Is that correct?  Could you maybe use a timed interrupt?

m_stroober

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 

lemster68

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.

graemepaulin

What if you go the other way and have coordinated motion with the MU200?