Posts by chocobo_ff

  • Continuous movement in a loop

    Sensor_Offset is updated in an interrupt that is set to run every 50ms, it's data over DeviceNet. Every interrupt Sensor_Offset is updated:


    Code
    DECL POS Sensor_Offset
...
Sensor_Offset.X = dir*const


    Where dir is a direction (1 or -1), and const is how much to move by, e.g. 10.


    I have just looked up advance run stop in the KSS 5.2 manual, this is what it says:


    Quote

    In applications where this advance run stop should be prevented, the command CONTINUE
    must be programmed immediately before the relevant instruction.


    So I'll try that soon and report back. Otherwise is there anything else I might be doing wrong?

  • Continuous movement in a loop

    Have updated the code and unfortunately still doesn't move the way I want it - continuously. I have tried different values of $APO.CPTP (5-100) and nothing worked ???


    Perhaps I am going about this the wrong way?


  • Continuous movement in a loop


    Thank you for the suggestion. I tried C_DIS but had an error (can't remember what it is off the top of my head). I will give this a try tomorrow :)

  • Continuous movement in a loop

    I am trying to move the robot based on external inputs, which updates a POS, P_offset, which is polled using a timer and updated in an interrupt. Timing of when P_offset gets updated is not critical.


    The main part of the code that moves the robot resides in a REPEAT loop. The robot follows the external input without problems, however it stops between each movement. I initially had:



    However this didn't work. I then tried to add a second pos in there hoping that it'll give the robot enough 'look ahead' to make the movement continuous, but this didn't work either:


    Software is v5.4. Any suggestions would be much appreciated :)

  • TCP remote maintenance tool

    We are having some issues with our CS8C controller, where the system is not booting up properly. When the power is switched on, the MCP is stuck at the Staubli logo page, and doesn't go into the menus after a minute or two. I've read in the SRS manual that there is a TCP remote maintenance tool, but there is no information on what software/configuration is required to access this, does someone have this information?


    For those interested, these are the error indicators on the controller:


      • RSI: the three LEDs for power status (D49, D50 and D52): D49 and D50 are on, D52 is off (5V from STARC board). We checked the power LEDs inside STARC (1.2V, 1.4V, 2.5V, 3.3V and 5V), all 5 LEDs are on, indicating that there is in fact 5V at the STARC board. 7-segment display has a flashing ‘E.’ (~1 second).

      • STARC: the 5 LEDs (A-E): D and E are on (orange), A and B are flashing slowly (red), C is off.


    Any suggestions/recommendations would be much appreciated.

  • CS8C error codes - U on the 7-segment display

    Our CS8C was working fine, and then I tried to add a gate sensor to UESB1+/-, but that did not work (turned out the gate sensor faulty), so I tried to short the two pins to close the loop (all the pins are connected to a terminal block), which is what we had it before I tried to add the gate sensor. Now the controller is having an error, "U". Looking in the manual, it says "EStop 1 order memorised ...", and I tried to disconnect UESB1+/- and then connect it back up again, but could not figure out how to acknowledge the error. When I disconnected UESB1+/-, the error code changed to "c", which according to the manual means the e-stop is activated, which is correct, but could not figure out how to get rid of the "U".


    From the MCP, under "Control Panel", "IO", "Controller Status", there is a fault with UESB1, but am unsure what that means as I thought I had connected the two pins up again correctly... the right most key says "Info", and according to the manual, this should say "Ack." (acknowledgement) if the error has been resolved.


    Please let me know if anything is unclear. Any suggestions/advice would be much appreciated.

  • Modbus - floating numbers

    I need to send some floating numbers (positions) to/from our TX200 with a CS8C controller using Modbus TCP. I have succesfully sent floating numbers FROM the controller to a PC, by setting the data type as "FLOAT". The PC receives this data as 2 words, which are then combined and converted into a single signed number. When I try to do the same in reverse however, the data is not received by the robot controller.


    The program on the PC is written in LabVIEW, and I manually split the floating numbers into 2 WORDs for each number, then written to multipl registers. If I change the data type on the controller from "FLOAT" to "DWORD" (double word), then the data is transmitted fine. If necessary I'll write my own function to do the conversion from 2 WORDs to FLOAT, but would prefer to use the FLOAT type. Since the controller can send FLOAT numbers fine, I wonder whether I'm not using the write send command or the data's in the wrong format...?


    Is there a documentation on Modbus for Staubli? I had a look on the Staubli tech support website, and there isn't much info on this topic.

  • Weird serial problem

    Did some more tests, it looks like the problem might be with MATLAB. Currently my MATLAB program sends a position when required, and polls for incoming data using a timer. When I removed the timer and hence polling for incoming data, the problem seems to go away. This leads me to think that maybe the incoming/outgoing parts of the code are clashing with each other (not something I expected from MATLAB).


    EDIT: tested with a serial splitter, data shows up fine on a 2nd PC when characters are dropped in the packet received by the KUKA...

  • Weird serial problem

    Yea I'm not sure if comma instead of whitespace is going to make any difference, like you said whitespace is just another ASCII character, plus sometimes it's the 0, 1 or 2 that we use to represent the different states that are missing.


    We tried using a serial splitter to listen on the data coming out from the PC, and when the KRC2 is not receiving the proper string, the second laptop we use to check the data is receiving it fine...


    Not sure if this is of any help, but the setting in serial.ini is below:


  • Weird serial problem

    I'm trying to communicate with our KRC2 via serial, sending position commands and sending back acknowledgement upon receiving them, but have been having a weird issue which I can't figure out. For the strings I send from MATLAB from another PC, there are 2 integers at the beginning of the string telling the KUKA what sort of move is required (PTP, LIN, CIRC), followed by (x,y,z,a,b,c), and (s,t) if it's a PTP, e.g. "0 0 x y z...", or "1 1 x y z ...". The problem is sometimes, the "0 0 " or "1 1 " (the type of moves) do not get received properly on the KUKA side. Looking at telnet on the KUKA (photo attached), sometimes this is received as " 00", " 0", "0 " etc (note the white spaces in the string).


    I have checked the MATLAB side, it seems to be sending the strings fine, I don't think the KUKA program is the issue, because the issue is with the incoming string and not the actual processing of it. It's also strange that this only happens in the first few characters of the string, so I doubt it's to do with the serial cable, but we are checking on that now.


    Any insights would be much appreciated :icon_smile:


    EDIT: in the image attached, the first received string is the correct format, the second one is messed up - it should read "0 0 -197..." instead of " 00-197..."

  • alter() usage

    I'm developing a program without a simulator/robot at the moment (still waiting for some people to get their act together and get me the robot!), and one of the functions I need to use is the alter() function. I'm a bit unsure about the structure of it as there's limited information in the documentation, could someone tell me if I'm doing things in the right places?


    In an async. function, I have:

    Code
    taskCreateSync "controller", dt, b_overrun, controller()

  // Start the alter() process.
  wait(alterBegin(t_flayer, m_sequence))

  alterMovel(appro(here(t_flayer, world), tr_sequence), t_flayer, m_sequence)

  // End the alter process.
  wait (alterEnd() == 1)


    And in controller():

    Code
    // Some code to process an analogue signal.
// Some code to compute the transformation required.


alter(tr_offset)


// More tidy up


    Does that look about right? The part I'm not sure about are the alterBegin() and alterEnd() functions.


    Many thanks in advance.

  • Replace Battery for KRC2

    Most definitely with the power off. Don't think there are manuals for replacing the batteries, but it's pretty simple. Take the old ones out, keeping track of how they are connected up (in series), then put the new ones in and connect them up in the same way.


    Sent from my LT26i using Tapatalk 2

  • VAL3 examples

    I've been using KUKA KR30 and KR60 for work, and now we are getting a Staubli TX200 for one of the projects I'm working on. I have read through the VAL3 reference manual, and have a good idea of how to program this robot, but was wondering if anyone can share an example project so I can study up on it while waiting for a simulation dongle and the actual robot to arrive? The time we have the robot with us at work is quite short, before it needs to be sent out to the client's site, so unfortunately I won't have as much time to play with the TX200 as I would like.


    Preferrably a VAL3 Studio project file, but beggers can't be choosers so any example code will be much appreciated :icon_smile:

  • Serial communication terminator

    Just a quick update, I think I've solved the problem of receiving data on the KUKA side, will post what I've done bit later when I have some free time, now just need to figure out how to append terminators when sending data from the KUKA side...

  • Serial communication terminator

    SkyeFire, could you please elaborate more on how you would do it in KRL? The next thing I need to do is send command back to an external PC, and I've done some quick tests, in MATLAB It says "Unsuccessful read: A timeout occurred before the Terminator was reached" (default terminator in MATLAB is \n). The serial port is set for synchronous writing, and the data was sent by:


    Code
    CWRITE(HANDLE,SW_T,MW_T,”%d”,IS_VALUE) ; INT IS_VALUE, IS_VALUE = 12345


    Also, going back to the reading on the KUKA side, I've tried appending \n, \r to the string from MATLAB, please see the first image for the values read by the KRC2 (output from telnet). The string shows various <0xD>, <0xA>, which I understand are \n and \r in hex form:


    Code
    SER[3]-RX: 0.000 ... 1.000000<0xD><0xA>0.000 ... etc ; data received in one string


    What I would like the robot to see is shown in the second image, where each string is treated separately, e.g.


    Code
    SER[3]-RX: -510... etc
SER[3]-RX: -510... etc ; data received in two separate strings


    This could be due to the way I'm sending the data in MATLAB. Is the correct terminator \r, \n or \r\n ?

  • Serial communication terminator

    I'm hoping someone can share some light to what I'm doing wrong or rather, the proper way to do serial communication on the KRC2 (software version 5.2).


    On the KUKA side, this is the code I have:



    And I'm sending data via RS232 from MATLAB on another computer. The code is:



    The reason I open/close the serial port on the MATLAB side for each send command is because if I don't, the data received on the KUKA side appears as one long string (from telnet), and the second read command on the KUKA side complains that there is no data available. My guess is I'm probably not applying the right terminator from the MATLAB side, but I'm not sure what to do. I've tried \r, \n, \r\n but with no luck.


    The flow control is set to XONXOFF, and I've double checked all the serial settings and they match up. Sorry I am not at work right now so can't provide much more information, but if something is not clear please advise and I'll see what I can do tonight, otherwise I'll get the required information first thing tomorrow morning.


    Many thanks.