Fast movement time logging

Eric1988

Hi,

 

I'm testing many (200 000+) movements and I log the times with the clock and I write them in a file.

 

Is there a way I could do this as fast as possible ?

 

The real time taken is not very important, the most important is that the times taken relative to each other are kept. For example, if in a super-fast simulation a movement takes 0.1 second and another one takes 0.2 second, well in real-life if the first movement takes 1 second then the other one would take 2 seconds.

 

I used vmax, accset, velset, virtual time to free run, accuracy to as fast as possible and timestep to lowest (12 ms).

 

Instead of using fine movements, I used z0 movements. EDIT : I'm back to fine movements because of time irregularities (A to B vs B to A), so it's again a factor slowing the simulation.

 

Is there any other way to try to speed this up ? Could that simulation be ran in background, not even showing the simulation, just running the intern algorithms to get the time ?

 

Thanks,

 

A%ric

Eric19882012-12-01 19:35:11

Marcel

Hi

You could use the MoveLSync instruction with z0 zone instead of fine zone. So the routine that you add at the end will be executed when the movement is close to the destination position. In that routine you could give out the time. It is the same time that also the real robot would have.

 

PROC rMove()

  ! move to position

  MoveLSync pStation1Center10,v1000,z0,tLaserWObj:=wTable1,"rCycleTime";

  MoveLSync pStation2Center10,v1000,z0,tLaserWObj:=wTable1,"rCycleTime"; ENDPROC

 

PROC rCycleTime()

  ! give out cycle time

  ClkStop cWorkingTime;

  ErrWrite I,"cycle time: "+NumToStr(ClkRead(cWorkingTime),1)+" s","";

  ClkReset cWorkingTime;

  ClkStart cWorkingTime;

ENDPROC

 

Best regards

 

Marcel

Eric1988

Hi,

 

Thanks for the advice, it would be nice, but all my movements are to absolute joint targets...

 

Too bad for me I guess !

 

Any other idea ?

Henrik Berlin

To speed up simulation as much as possible you should use
* Free-run mode
* "As fast as possible"
* Largest time step



Also, to get correct cycle times you must use fine point for the last motion instruction prior to starting or stopping the watch (or use MoveLSync as pointed out above).

Eric1988

Oh thanks, I was reducing the timestep instead of increasing it.

Eric1988

And would it be even faster when running the 64-bit version of RobotStudio ? My computer is 64-bit, but it seems that RobotStudio didn't install in 64-bit...

Henrik Berlin

The performance difference is small between the 32 and 64-bit versions. The main advantage is that the 64 bit version can handle large CAD-models.

What OS are you on? RobotStudio 64-bit requires the 64-bit version of Windows 7 or 8.

Eric1988

I have Windows 7 64-bit.

RobotStudio installed in Program Files (x86), I don't remember why. I think I didn't do the "complete installation" and that could be why ?

 

Also, I don't really see a speed difference and I don't know why. I'm timing the total code execution time with clock instruction and it wrote down my file "83 000 seconds" (A bit more than 19 hours), but it took about 35 hours. And that was with normal simulation speed (100%).

 

I started back with modified options and after an hour, from then average time I calculed manualy, it would also take about 35 hours.

 

The code is mostly about doing near 95 000 MoveAbsJ and clocking the moves, using IRB120. It's taking an average of about 1.3 seconds of real-life time (Around 124 000 seconds [~34 hours]), while the sum of all the clocked times gives me about 83 000 seconds [~23 hours] and I don't think that passing through the for-loops and writing to text file are the remaining 11 hours, it's more like 1000 seconds added [~16 minutes] from my last test.

 

I'm currently running RobotStudio 5.15 (32-bit so far, and free unactivated version) on a laptop : Windows 7 Premium Family Edition  i7-3610QM @ 2.3 Ghz 2.3 Ghz, 8 Gb RAM, Intel HD Graphics 4000 integrated / nVidia GeForce GT 630M 2 Gb.

 

Thanks,

 

A%ric

Eric19882012-12-06 17:23:54

Henrik Berlin

The simulation may be slower or quicker than what it would be on the real controller depending on the number of controllers and your pc, etc. etc.. However, the process times you get in RS (with Time Slice option) or in VC using ClkStart/ClkStop will match the real cycle time reasonably well.