Posts by snewk

  • Deploy code to robot with github actions

    Quote from massula

    are You saying that these files are being inserted on WorkVisual Project, or in WorkVisual repository created by WorkOnline function?

    I'm not familiar with WorkOnline. Google doesn't seem to return much, but I see you've mentioned it a few times on the forum. Will read more about this, thanks.


    Quote from SkyeFire

    If your main goal is to support multiple people working on a single shared code base, it gets trickier.

    SkyFire, this is essentially what we are looking for here. We've used Dirloader in the past. Its tricky, but probably will work for our purposes. I wonder if it might be possible to actually set up the D drive transfer folder as a git repository for dirloader to copy files out of. Using comments for versioning sounds like a huge PITA. Would love to avoid that if possible...

  • Deploy code to robot with github actions

    I might get flamed for this question, but here goes nothing.

    I'm a developer/integrator working primarily with Kuka robots (KR C4 and KR C5). We have grown a lot in the past few years, and have added additional software developers to the team.

    With our influx of developers we have started using git for version control on our software. These repositories use manually uploaded robot archives to track key files on the C drive and the KRC directory, but we still haven't solved a "graceful" way to deploy this code back to the robot. Currently we are manually copying files from our version controlled git directory into workvisual. This is obviously a pain in the a**, does not scale well, and is prone to errors if a dev is not meticulous about ensuring files are copied correctly.

    Does anyone here have a better solution for git version control of robot code?

  • Editing Reference Tool in Inline Form point programmatically

    I'm writing a program designed to capture 7 points around an initial start point. The user will not play the program using any of these points.

    First, we capture the initial point, then each movement is executed via geometric offset from this point. After each movement, a list of points (originally created via inline form) is updated to $POS_ACT. I would like to allow the user to run this program with any tool, however when I created the program I used Tool1, so all my inline form points reference tool1.

    Is it possible to programmatically change the reference tool for a point captured via inline form?

    See code below:

    System is a KRC4 KR120 R3100-2 on KSS 8.6.12

  • Data Inconsistency detected for Base Kuka KRC4

    Ok, so it seems this is related to C:\KRC\USER\MEASUREMENTPOINTS.xml as Danny suggested.

    After I write to BASE_DATA, the base information is stored in $config.dat and it is valid for use in program, however this updated base data is not reflected in measurement points unless the user opens the Tool/Base Management HMI. This is also when the notification message pops up.

    I suppose we could avoid the notification if we were to take the additional step of writing the base data to measurementpoints.xml, but it seems unnecessary now; I understand what is causing the notification, and it is simply a "notify" message.

    Skyfire, this system does not have mXAutomation installed, and searching through the project archive for BTM was a bust. I'm now thinking BTM stands for BaseToolManagement, since this is the active HMI at the time of the message (KukaRoboter.SmartHMI.BaseToolManagement).

    Panic, Apologies for not sharing more of the code. This code is highly modularized, and there are at least a dozen different functions controlling reading/writing/sending/receiving data over ethernetKRL which makes sharing it rather cumbersome. None of this is done in the submit loop, and the input buffer data is indeed validated before being written to any variables. I will also remove the sps reset since it's unnecessary :smiling_face:

    Thanks to all three of you for your help figuring this out!

  • Data Inconsistency detected for Base Kuka KRC4

    Quote

    no, there is nothing other than your code that is modifying base data.

    Perhaps my question was ambiguously worded. Is data for bases stored anywhere other than $config.dat?

    Quote

    what is the purpose of restarting submit?

    When opening $config.dat on the controller, the system will automatically stop the submit. I assumed stopping submit in my program would prevent the "data inconsistency" message.

    Quote

    why did you truncate the message? what is the COMPLETE message and value of that base?

    Frustratingly, there are multiple function calls within this program making it difficult to share the entire code in one snippet. The variables are declared as follows:

    Code
    INT rNewBaseID
CHAR rNewBaseName[24]
FRAME rNewBaseFrame

    I have verified the data received on the controller for rNewBaseFrame is a properly formatted frame:

    {X 1596.34741,Y -471.842,Z 539.848816,A -90.9623795,B 0.0270521715,C 0.136301115}

    In fact, the base data and name are even successfully written into $config, and I can verify this by checking Tool/Base Management.

    The message "BTM 23, Data inconsistency detected for base" still appears, however. I could simply ignore it, but I'd like to understand why the robot is warning me in the first place.

  • Data Inconsistency detected for Base Kuka KRC4

    Bumping this thread.

    I'm working on an automated base teaching program using a Renishaw touch probe. We use EthernetKRL connected to Renishaw's probing software to capture point data and calculate the plane for our new base.

    Once the robot receives this information, our probing program stops and deselects sps, writes off the updated base information, then restarts sps. I'm still getting the error message above in the original post.

    My question is this: Is there somewhere else in the controller where this base data is stored that could be causing this "inconsistency"?

    Robot: KR210-r2700 KR C4 on KSS 8.6.10

  • Heater PID Control in SPS

    Thanks hermann and panic.

    We have traditionally used thermal pid controllers for this task, but we wanted the ability to set and read temps directly on the teach pendant while also simplifying the BoM, hence the direct control in sps.

    For now we decided to go with the pulse method and it seems to be working well. Using multisubmit crossed my mind, however it still doesn't solve the edge case where the power output is TRUE and all submits are off.

    One thing i still may try is to map the system variable $PRO_STATE0 to an output group and then trial-and-error my way into finding a single unique bit from that group which is only true when the value is #P_ACTIVE. I honestly doubt this will work, so i'll probably just add a thermal fuse to the circuit.

  • Heater PID Control in SPS

    I am attempting to write a PID control loop which I intend to run in either the system submit or potentially in a separate loop using multisub. This function will control power to a heater based on a temperature input. One problem is that if the heater is powered on when a user opens sps for editing (or if sps crashes), the submit interpreter will no longer be running and power will remain on indefinitely.

    A potential safeguard would be to check the state of the system submit interpreter via $PRO_STATE0, and set an output connected to a relay which would disconnect power to the heater. Generally, I would check $PRO_STATE0, but without using submit itself I am not sure how to set a boolean when $PRO_STATE0 <> #P_ACTIVE.

    A second option would be setting a brief ~500ms timer and have the submit loop reset the timer each time it cycles. With this method, I could use the $TIMER_FLAG boolean to evaluate if the submit interpreter is no longer running. The problem here is that "SIGNAL $TIMER_FLAG[n] $OUT[n]" is not syntactically valid according to workvisual.

    My only other thought would be to never set the output to TRUE directly, instead using PULSE so the power is only ever on for a defined duration.

    Feels like I am overthinking this.... Looking for a sanity check here :loudly_crying_face:

    The system in question is a KRC4 KR150 on KSS 8.6.9

  • $Spindle System Variable

    This system is built around a kr210 r2700-2.

    From my machine.dat:

    $KINCLASS=#STANDARD

    $MAIN_AXIS=#NR

    $WRIST_AXIS=#ZEH

    you are correct about the values of all the above variables.

    Just to satisfy my curiosity, would you have an idea of what type of robot/configuration might have a "spindle axis"? I am unfamiliar with this term.

  • $Spindle System Variable

    I was poking around in Mada\$machine.dat and came across the following:

    Code
    INT $SPINDLE=0 ;SPINDELN (0 = NEIN, 1 = JA)

    Unfortunately, searching the forum for "$Spindle" turned up a ton of results with just the word "spindle" and not really anything related to this specific system variable. There is also no reference to this in the Kuka System Variables manual, nor the System Integrator manual.

    Does anyone have insight as to what this actually does? My intuition is that it could potentially tell the system the installed tool is symmetrical around the tool axis, thus allowing the motion planner to reach a given position at any orientation around tool X.

    This would be a big help to me, since most of the machines I work with are milling and 3d printing robots :upside_down_face:

Advertising from our partners