Well, the error message is not very helpful -- WorkVisual still has issues, there. The only time I've encountered anything even remotely similar was when there was an unnoticed change to $MACHINE.DAT that caused a Safety Configuration error, but without posting an error message on the SmartPad. I would suggest going to Safety Config on the SmartPad while logged in as Safety Maintenance and see if any warnings pop up.
Posts by SkyeFire
-
-
USB recovery stick can be used to make HDD image and restore from.
the message you get is from BIOS, it has problem reading your HDD, possibly not recognizing the HDD.He has a KRC2, not a KRC4. Do the recovery sticks work on any of the KRC2s?
-
You've provided no details about controller, software version, option packages, hardware, sensors, etc. Also, "when I teach, Vacuum is off" -- what does that even mean?
-
"KRC2" is a controller model, not KSS version. I'm going to assume that your KSS version is something between 5.2 and 5.6.
During my limited time with RSI, I never experimented with the ST_MOVESENS parameters, but I did quite a bit of work using ST_MOVESENS(0), and it functioned well.
From experience, I can say that 0 causes the KRL program to move on to the next line following the MOVESENS once the Break condition is triggered. I'm going to hazard a guess that a setting of 1 would allow the MOVESENS to continue once the Break signal is dropped, letting the Break act more like a "pause." Perhaps 2 allows the MOVESENS to continue from where it was interrupted upon the receipt of a start signal?
Either way, that Mode variable only controls how the MOVESENS object behaves in the event of a Break. It should have no effect on how the move starts.
-
I'm more concerned about the other .INI files. Even with a bad MFC DevNet config, I've never seen errors like this occur -- worst case, I got DevNet-specific errors. Those other .INI files should be entirely unaffected, no matter how messed up IOSYS is. Quickest way to check would be to comment out the DEVNET=2 line in IOSYS -- that'll turn off the Devnet entirely and render all other DevNet settings ignored. If you still have file-read errors at that point, I suspect a more serious problem.
Honestly, my first thought is to re-install KSS and see if that helps. My second thought is to wonder if there's a hardware issue on the MFC card that could cause these various errors.
-
Well, I was thinking more of just checking the Base data, but either way could work. Something like:
Code
Display More; in the .DAT file DECL FRAME BaseMemory = {....} DECL REAL DeltaLimit = 1.0 ; minimum 3D difference in mm ; in the .SRC file DECL REAL DeltaX, DeltaY, DeltaZ, Delta3D DeltaX = $BASE.X - BaseMemory.X DeltaY = $BASE.Y - BaseMemory.Y DeltaZ = $BASE.Z - BaseMemory.Z Delta3D = SQRT((DeltaX * DeltaX) + (DeltaY * DeltaY) + (DeltaZ * DeltaZ)) IF (Delta3D < DeltaLimit) THEN HALT ENDIF ; ; rest of program here BaseMemory = $BASE ; record current base for comparison to new base on next run
-
Greetings to all and excuse my intrusion in this thread.
I am a teacher an i need your help because during an experiment the arm was planted on the table during touch-up(probably caused from an operator error)
Now after freeing the arm from the table no longer starts because is entered in external blocking.
the error descriptions are: "kss00001" and "kss00020"
Can you give me some indications in order to release the arm?Best regards Marco Cagnetti
What model robot, what model controller, what version of KSS?
-
Are you using the points to generate new Base or Tool data?
If every part comes in a bit differently, you could use a memory variable for storing the Base data (for example). Store the Base data in this variable at the end of each program run. At the beginning of each program, perform a check of the memory against the "new" Base data. If they match too closely (say, out to the second decimal place) then the operator failed to build the new Base and you can have the program halt and post an error message.
-
Problem is, $FLAG is a system variable array, so you can't change how it's declared. I think that $FLAG is supposed to be retentive anyway, but I don't recall ever testing it explicitly.
Honestly, I generally recommend against using memory flags of any kind for this kind of operation -- checking the sensor inputs of the tool changer directly, in realtime, is far more reliable. Of course, sometimes you may be stuck with a hardware configuration that does not make this option possible.
-
Only using the angles B (y-axis) and C (x-axis) this can not be done. Orientation control of the robot is done with respect to the qualified x-Axis of the tool. That is the robot controller uses 2 degrees of freedom to bring any initial orientation to the desired destination orientation. These 2 dof are 'twisting' and 'turning' of the tool x-axis (and not as your implicit assumption of B and C suggests the tool z-axis!)
Fubini
I think he means tool axes B and C, which would make sense -- rotating around Tool A wouldn't have any effect on rotating the Tool Z axis to point at the second position. Now, the A value will definitely change, but that's just due to the transform.
In order to determine the final ABC we need... hm. Well, we have the XYZ positions of both points. Finding the Delta X/Y/Z is trivial. Then we just need to convert that into an A,B,C sequential rotation relative to the active Base. So, we reduce it to three planar calculations: The XY plane, then the XZ plane, then the YZ plane.
So, for the XY plane, visualize the vector between the two positions as seen from the Base Z+ direction. Treat Position 1 as the origin, and project the Delta X and Delta Y. An ArcTan calculation using the Delta X and Delta Y values should give the final A value desired.
However, the next planar projection would have to take the first rotation into account. Hm. This shouldn't be too hard, but I'm having a hard time visualizing it completely. I'll have to look into it some more when I have more time. -
To expand on what Panic said, the SPS is NOT a safety-qualified system. Attempting to use the SPS for safety-critical control can easily result in lethal consequences.
Unless you are using a KRC4 with ProfiSafe, or one of the other Tech Package options that Panic mentions (like SafeOperation), your only safety-qualified control inputs are the X11. Unless your KRC is very old, every X11 signal exists as a dual-channel pair, and each half of the pair must operate together to avoid creating a single-channel fault.
The "Operator Safety" signals on the X11 will prevent the robot from operating in AUT or EXT modes unless both Operator Safe contacts are closed, but will still allow the robot to be operated in T1 or T2 modes. Normal practice is to tie these X11 inputs to the perimeter guarding (light screens, safety gates, etc) such that if a human comes within physical reach of the robot, the robot loses Operator Safety, bringing the robot to a halt.
E-Stop buttons should be wired in series, and control the state of the E-Stop signal inputs on the X11.
-
Let me see if I have this correct: You want to move the TCP to Position 1, then rotate in place to point the TCP Z axis at Position 2? While keeping the TCP physically at Position 1?
-
A4 and A6 can work together at high speeds for PTP motions. However, for LIN motions, if A5 is too close to 0deg, A4 and A6 will attempt to compensate by rotating in opposite directions at increasing speed until an over-speed fault occurs.
-
The motion around the 20sec mark looks exactly as I would expect. The motion taking place from 40sec to 59sec looks as if A4 is attempting to rotate more than once?
-
The problem is most likely the precompiler lines in the header of the .SRC file. If those are missing or improperly configured, this is the result.
If you examine a "normal" .SRC file, like CELL.SRC, from the robot using OrangeEdit, and change the OrangeEdit View option to ASCII, you will see these lines at the top of the .SRC file. Normally, they are hidden. These are the lines that begin with a & character. You may need to copy these lines into your .SRC file.
-
I think that ST_SETPAR has been replaced by the SetPublicPar function, but I'm not entirely certain. Haven't had much chance to work with 3.1 yet.
-
Well, I'll try it both ways once I have access to a free KRC4 again.
-
File sharing shouldn't consume any CPU cycle unless there is read/write activity going on. When the connection is dormant, there should be no effect.
Also, since file sharing is a Windows activity, it will have no effect on the robot's operation. If the CPU becomes short of resources, VxWorks takes priority over any and all Windows tasks.
-
Depends on wrist design. In general, A4-A6 share a gear train, so to move one axis while keeping the others stationary may require turning all three motors -- one to move the commanded axis, the others to counteract the gear train side effects cause by turning the first motor. But, looking at the actual wrist joints, ideally one should see no motion on A5 or A6 when moving A4 in isolation -- the motors may turn, but the physical axes and the values of $AXIS_ACT should not. I assume that $COUP_COMP defines how much "counter-driving" each axis needs to offset the side effects of turning one of the others.
-
Again, does your TCP start and end at the same location, or not? Does the TCP end at the correct location?
That video is not an example of changing S&T, it's a deliberately crafted example of wrist singularity. Unless your A5 angle is exactly0, you are not going to achieve that same effect. Any PTP motion will cause the TCP to drift to some degree between the start and end of the motion, even if the start and end points are identical.
Also, since you are introducing a situation guaranteed to create axis backlash issues, you will always see some degree of error even if the cartesian coordinates of both points are identical. Just how much error are you seeing?