Background calculation with TCP Speed
Hello everybody,
I would like to calculate the wire speed of a wire feeder depending on the actual TCP velocity. Therefore I use an Interrupt every 0,1s (with iTimer). Unfortunately the minimum time of 0,1s are a little bit too slow. Is there any possibility to do a background calculation faster than this? The robot moves with max. 75mm/s and in certain areas I sometimes have ~7mm long sections with to less wire inside, if the calculation is done in a place where the tcp speed was a little bit lower because of a reorientation.
The analog Output with the TCP Speed updates 40ms before the Robot reaches his actual velocity. With the Parameter "Event Preset Time" it should be possible to increase the lead time up to 0,5s. But when I enter a certain value for this Parameter I don't see any effect. Do you know weather I need a certain I/O to knid of activate this Parameter?
Thanks and best regards,
Bert
Answers
-
A background task should have no problem constantly updating the wire feed signal based on the TCP speed signal -- I'd guess that the practical max speed of a background task depends on the speed / age of your hardware. I'd give 0.01 seconds a try and see if you notice any controller / pendant sluggishness.
0 -
So are you using arcware? If not you might want to use TrigLAO.Lee Justice0
-
soup said:A background task should have no problem constantly updating the wire feed signal based on the TCP speed signal -- I'd guess that the practical max speed of a background task depends on the speed / age of your hardware. I'd give 0.01 seconds a try and see if you notice any controller / pendant sluggishness.
Thanks for the answers!
Unfortunately it is not possible to lower this value. The manual says the minimum value for iTimer is 0,1s. I also tried to use 0,01s but then I get an error message.
lemster68 said:So are you using arcware? If not you might want to use TrigLAO.No I don’t use it. It is for a laser brazing process.
First I used the normal TriggL instruction to trigger a new Group Output for the speed of the wire feeder at certain places. But I would like just to start the feeding process in the beginning of the part with a trigger and have a background task, which calculates the needed wire speed.
I add a graph with the calculated wire speed (Set Value) and the actual wire speed. The main problem is the delay (red "circles"). I think this lag comes from the slow calculation, the lag from the fieldbus and the sluggishness of the wire feeder. In which the sluggishness has the biggest impact and is something around 0,2s – 0,3s.
Do you have an idea how to handle this lag? My first try was to increase the “Event Preset Time” but I did not notice any changing.
Thanks,
Bert
0 -
@BertK -- I'm not sure about using iTimer in the background task -- I was referring to trying a 0.01 second waittime in the background task so it doesn't update too much and pull too much processing power. Example below. You can have up to 20 tasks so I was suggesting a dedicated task to nothing but checking the inputs and quickly output the wirefeed speed.
MODULE mExampleBackgroundTask(SYSMODULE)
PROC main()
WaitTime 0.01;
IF diWelding=1 AND AOutput(aoTCPvelocity)>0 THEN
SetAO aoWireFeed, AOutput(aoTCPvelocity)*1234;
ELSE
SetAO aoWireFeed, 0;
ENDIF
ENDPROC
ENDMODULE
0 -
In your first post, you said you are using an AO and mentioned TCP speed. I figured you had set up the system output for TCP speed. In this case, the event preset time should work to adjust for the lag. However, in your last post you said group output, which is it?Lee Justice0
-
@soup Ok thanks, I will try this. Do I need a certain instruction in the main task to call such a background task?
@lemster68 It is only possible to get the TCP Speed as an AO. But the velocity of the wire feeder is a GO. I use a certain scaling factor to get the right value for the GO which is calculated in an interrupt.
I also tried to change the value of the event preset time but didn't noticed any differences.
0 -
You don't really have to have an analog card for the TCP speed output. You can map it to a digital IO board and it works like analog. If you need an example, I can post it.Lee Justice0
-
An example would be great!
Thank you!
0 -
This comes from a sealer robot, RW 5.x, as you can see, we have mapped the "AO" over profinet, not an analog.
I think this has all the relevant info for you. Good luck!-Name "nordson" -UnitType "PN_GENERIC" -Bus "Profinet_SW"#EIO_SIGNAL:-Name "aoEqu1F1" -SignalType "AO" -Unit "nordson" -UnitMap "32-43"\-EncType "UNSIGNED" -MaxLog 100 -MaxPhys 10 -MaxPhysLimit 10\-MaxBitVal 4095Lee Justice0 -
I am thinking that your issue with event preset time and the background task setting values is because there is no "event". E.g., TriggL, TCP speed system output and the like. These things are "events".Lee Justice0
Categories
- All Categories
- 5.5K RobotStudio
- 396 UpFeed
- 18 Tutorials
- 13 RobotApps
- 297 PowerPacs
- 405 RobotStudio S4
- 1.8K Developer Tools
- 250 ScreenMaker
- 2.8K Robot Controller
- 316 IRC5
- 61 OmniCore
- 7 RCS (Realistic Controller Simulation)
- 800 RAPID Programming
- AppStudio
- 3 RobotStudio AR Viewer
- 18 Wizard Easy Programming
- 105 Collaborative Robots
- 5 Job listings