RobotStudio event

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

  • soup
    soup ✭✭✭
    edited June 2018
    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.
  • lemster68
    lemster68 ✭✭✭
    So are you using arcware?  If not you might want to use TrigLAO.
    Lee Justice
  • 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

  • soup
    soup ✭✭✭
    edited June 2018
    @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



  • lemster68
    lemster68 ✭✭✭
    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 Justice
  • BertK
    BertK
    edited July 2018

    @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.  

  • lemster68
    lemster68 ✭✭✭
    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 Justice
  • An example would be great!

    Thank you!

  • lemster68
    lemster68 ✭✭✭
    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 4095

    Lee Justice
  • soup
    soup ✭✭✭
    @BertK No, just need to add the task and give it a starting point (main).
  • @soup it is possible to calculate the wire speed faster with the second task as with the Interrupt. Thanks for the help! With 0,01s it seems to be even a little bit to fast for the wire feeder :) It somethimes stopped to refresh the set value.
  • soup
    soup ✭✭✭
    @BertK All good or still working on the second part of your question?
  • @soup still working on it. Any idea? :)

    I will try to do a signal analysis with RobotStudio. Maybe I will see some influence from the  "Event Preset Time", which I haven't noticed before.

  • lemster68
    lemster68 ✭✭✭
    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 Justice