You wrote a wrapper routine to load a vision job onto the integrated camera, the program check stops dead on one line, and the message is Type error(83): cameradev not value type. The fix is one word long, confirmed on a controller running RobotWare 6.09.02.00, and it touches neither your call sites nor your camera configuration. Prefix the parameter with VAR in the routine header and the error is gone. This walkthrough shows why that prefix is required, which other RAPID data types demand the same treatment, how to prove the fix on the controller, and when to sidestep the integrated camera interface with a standalone vision sensor instead.
Why does RAPID stop with Type error(83) on a cameradev parameter?
Because cameradev is a non-value data type, and RAPID accepts a non-value type as a routine parameter only when the parameter is prefixed VAR; a plain cameradev CamName header is an illegal combination, so the program check stops with Type error(83): cameradev not value type.
The message is a semantic error, not a syntax error: the line parses, but the combination of usages is illegal. A plain parameter is a value position, and cameradev cannot fill one. The Technical reference manual - RAPID kernel covers this in its DATA TYPE VALUE CLASSES section; its table, Possible and impossible combinations of object usage and type value class, lists which combinations survive the program check. A non-value type in a plain parameter position is one of the impossible ones.
PROC rLoadVisionProg(cameradev CamName, string ProgName)
! camera instructions that use CamName go here
ENDPROC
The routine and parameter names here are illustrative; the types, the error text and the prefix are the documented part. With that header the check stops at the PROC line and reports Type error(83): cameradev not value type.
What are the three value classes in RAPID?
RAPID sorts every data type into one of three value classes — value, semi-value and non-value — and the class decides where a type may be declared, how it may be passed, and which instructions accept it.
A value type represents some form of value: num is the standard example, and string and record types belong to the class as well. A non-value type stands for an object that cannot take part in value-oriented operations, so there is nothing to copy into a parameter. Semi-value sits between the two — the RAPID Overview manual notes the signal types were moved to semi-value, and the kernel manual describes a semi-value object as having a basic non-value type behind it. For routine parameters the two lower classes share one rule: plain refused, VAR accepted.
| Value class | Examples in the manuals | Plain parameter | VAR parameter | Usable by data-reading instructions |
|---|---|---|---|---|
| Value | num, string, record types | Yes | Yes | Yes — atomic, string and record only |
| Semi-value | signalai, signaldi, signalgi | No | Yes | No |
| Non-value | cameradev | No — Type error(83) | Yes | No |
How do you write the header so the program check passes?
Prefix the parameter with VAR — PROC rLoadVisionProg(VAR cameradev CamName, string ProgName) — and the semantic error disappears at the next program check, with no change at the call site.
PROC rLoadVisionProg(VAR cameradev CamName, string ProgName)
! camera instructions that use CamName go here
ENDPROC
VAR is the keyword that declares a variable in RAPID, and in a routine header it switches the parameter from a value copy to a reference. That is the only form in which a non-value type may cross a routine boundary. The call site stays exactly as it was; the camera reference goes in as the argument, unchanged.
Why must cameradev never be defined in the program?
Because the camera object is created outside your RAPID module: the datatype rule states that cameradev data must not be defined in the program, and an instruction that refers to a program-defined cameradev raises an error as soon as it executes.
The camera itself is configured in the controller's camera system — ports, addresses and I/O — not by a line of RAPID; the ABB IRC5 integrated vision camera setup: ports, IPs and I/O errors guide walks that side. Your module receives the reference and forwards it, it never owns it. That is also why the VAR prefix is legal where a definition is not: a prefix in a parameter list is a passing mode, not a declaration, and no cameradev data comes into existence because of it.
Which other data types trigger the same error?
Every semi-value and non-value type does: signal inputs signalai, signaldi and signalgi are semi-value, tooldata and wobjdata are semi-value as well, and each needs the same VAR prefix when it appears in a routine header.
PROC rWaitForPart(VAR signaldi diPartPresent)
! instructions that act on diPartPresent go here
ENDPROC
signaldi is listed as semi-value, so it takes the VAR prefix in exactly the way cameradev does. One boundary stays closed, though: the RAPID reference manual restricts instructions that read data to value data of atomic, string or record type, and states that semi-value and non-value data cannot be used there. No prefix fixes that case — you convert to a value first or use a different instruction.
Is a switch parameter a way around it?
No — switch is a separate mechanism: the manuals define it for optional parameters whose argument is given by name alone and carries no value, so it cannot replace the VAR cameradev reference your camera instructions need.
A switch argument is written as a name at the call and nothing more; it is how optional behaviour gets turned on. It never carries data, so it cannot move a camera reference past the value-class rules. Use switches for on/off options on your wrapper routine; keep the camera itself as VAR cameradev.
How do you prove the fix on the controller?
Re-run the RAPID program check after the one-word edit: Type error(83) clears from the error list immediately, because the header now matches a legal combination in the kernel manual's usage table.
- Change only the header, to
PROC rLoadVisionProg(VAR cameradev CamName, string ProgName), and leave every call unchanged. - Run the program check again; the Type error(83) entry for this routine disappears from the list.
- Search the program for any declaration of cameradev data; there must be none, because that rule is enforced at execution, not at the check.
- Execute the routine with the camera reference your camera instructions already use, and confirm the camera carries out the job.
Before the live run, confirm the cell's safety configuration is active for the test — are robot safety settings active during hand-eye calibration? shows where that check lives.
When should you skip the integrated camera interface altogether?
Skip the integrated camera interface when the inspection outgrows it: a standalone smart camera or a vision controller runs the inspection itself and reports results to the robot over Ethernet, so no cameradev parameter exists in your RAPID code at all.
Smart cameras run detection on the device and hand the robot a result; receiving vision data in RAPID over TCP sockets: how it works covers the RAPID side of that exchange. For what belongs on the sensor itself, AI vs rule-based smart camera inspection: how to choose gives the decision path, and ABB integrated vision with a third-party camera: your options lays out the middle ground of keeping the robot controller you have with a camera of your own choosing. If the camera ends up riding on the arm, robot mounted camera calibration: capture and solve covers the calibration half of that change.
The MV-SC5060XM-08M-WBN is a 6 MP mono smart camera from the SC5000X series: a 1/2.4" sensor, an 8 mm M12-mount lens and a GigE interface.
- Interface
- GigE
- Resolution
- 6-10 MP
- Sensor format
- 1/2.4"
- Shutter
- Rolling
When the vision work belongs on a fanless industrial computer instead — several cameras, heavier processing, results for the whole line — the vision controllers category carries them. The MV-VC3301H-128G66 runs an Intel Core i3 processor with 8 GB memory, a 128 GB SSD and 4 built-in light output channels.
- LAN ports
- 5+ LAN ports
- USB 3 ports
- 3-4 USB 3 ports
- Light outputs
- 4 built-in channels
- Memory
- 8 GB
What should be true before you close the editor?
Five things: every semi-value or non-value parameter carries VAR, no cameradev declaration exists anywhere, forwarding routines repeat the prefix, value types stay plain unless modified, and no call site changed.
- Every semi-value or non-value parameter in every routine header carries the VAR prefix.
- No cameradev data is declared anywhere in the program — the reference only ever arrives as an argument.
- Any routine that forwards the camera reference repeats the same VAR prefix in its own header.
- Value types such as string and num stay unprefixed unless the routine must modify them.
- The call sites are untouched; only headers were edited.
If all five hold, the routine is ready to hand back to the cell.
Questions
Why does string ProgName compile without VAR?
string is a value type, so it is legal in a plain parameter; the value-class rules only block semi-value and non-value types there. Add VAR to a string parameter only when the routine must modify the argument and hand the new value back to the caller — for a read-only job name, the plain form is the correct one.
Can I declare VAR cameradev Cam1 inside the routine instead?
No. The datatype rule forbids defining cameradev data in the program at all, and the VAR in a parameter list is a passing mode, not a declaration — no camera data comes into existence because of it. Define cameradev data anyway and the module still checks clean, then trips when the referring instruction executes.
Do tooldata and wobjdata parameters need the same prefix?
Yes. tooldata and wobjdata are semi-value data types, the same class as the signal types signalai, signaldi and signalgi, and the kernel manual's usage table requires VAR for every semi-value or non-value parameter. A header written as (VAR tooldata tGrip) is the matching fix for those routines.
Is error 83 raised before the program runs?
Yes. It is a semantic error from the program check, raised while the module is verified and before any motion or camera command executes. That separates it from the run-time failure caused by defining cameradev data in the program, which only appears when the referring instruction actually runs on the controller.
Does the fix change how the routine is called?
No. The argument list at the call site stays exactly as written; you pass the same camera reference you already use with the camera instructions. Only the routine header changes, because the error was about the parameter declaration, never about the argument, and any routine you forward the reference to needs its own VAR prefix.