Dashboard Server getVariable returns a sampled value, not a continuous trace. The number that matters is the polling interval relative to the shortest state dwell time: if a program variable changes faster than the client queries it, the dashboard can miss the transition. This is timing, not control logic. Use the command for remote observation; use the robot program or a controlled PrimaryInterface workflow when a value must change.
State, timing, and access limits
getVariable var_1 can read an installation variable or a variable in the currently running program. The returned value represents the state available when the request is processed. It does not prove that the value remained constant before or after that sample.
A supervisory client therefore has two separate design questions: whether the variable is visible in the current program context, and whether the polling rate can capture its shortest meaningful state. For a one-scan flag or another short-lived condition, expose a latched diagnostic variable in the robot program and clear it through defined program logic. A raw poller cannot reliably capture a pulse whose dwell time is shorter than its complete request-and-response cycle.
| Quantity or limit | Engineering consequence | Where to read it |
|---|---|---|
| Current variable value | Shows one sampled program or installation state | Response to getVariable var_1
|
| Variable scope | Determines whether the name exists outside the active program context | Robot program and installation configuration |
| State dwell time | Sets the fastest transition that polling can observe reliably | Program logic or a timestamped diagnostic variable |
| Client polling interval | Must be shorter than the minimum state dwell time when every state matters | Dashboard client timestamps |
| Write authority | Dashboard reads do not provide a demonstrated variable-write path | Interface response and subsequent readback |
| Program interruption | Script injection through PrimaryInterface can pause the main Polyscope program |
Program state before, during, and after the write attempt |
Variable access approaches compared
The usable approaches divide by purpose. A read-only dashboard query has the smallest operational effect. A robot-program assignment preserves program ownership of runtime state. A PrimaryInterface script can introduce an external write path, but writing a running program variable this way can pause the main Polyscope program. Installation variables offer a controlled handoff: write the installation variable through PrimaryInterface, then start the program that consumes the new value.
| Approach | Read or write | Program impact | Best use |
|---|---|---|---|
getVariable var_1 through Dashboard Server |
Read | No write action is demonstrated | Remote status and program-flow diagnostics |
| Assignment inside the robot program | Write | Runs under normal program control | Changing active program variables |
Script sent through PrimaryInterface
|
Write | Can pause the main Polyscope program | Controlled service actions where interruption is acceptable |
Installation-variable write through PrimaryInterface, followed by program start |
Write, then consume | Coordinates the update with program startup | Externally supplied values needed by the next run |
For monitoring, use getVariable as a read-only diagnostic channel. For external setpoints or recipe data, prefer an installation variable updated during a defined stopped-state transaction, then start the program and let program logic validate and copy the value where needed.
Read-only dashboard procedure
- Identify whether the target is an installation variable or a variable owned by the active robot program. Confirm the exact spelling and case in the robot configuration.
- Connect using the existing Dashboard Server client. Preserve the same framing and request handling already used for documented dashboard commands; the evidence supplies the command token but no alternate transport settings.
- Send
getVariable var_1, replacing onlyvar_1with the required variable name. - Record the raw response together with a client-side timestamp. Treat malformed, empty, or unexpected responses as communication or compatibility failures rather than as valid process values.
- Repeat the read while forcing the robot logic through known states. Compare the dashboard response with the value displayed or used by the robot program.
- If every short transition must be detected, change the robot logic to latch the event or increment a counter. Poll that persistent diagnostic value instead of the transient flag.
Keep dashboard reads outside safety functions and deterministic sequencing. A diagnostic poll traverses software and communication layers whose latency is not bounded by the evidence.
Controlled write procedure
No working Dashboard Server variable-write command is established. Attempts using setvariable var_1, set var_1, and set_variable var_1 were unsuccessful. A client must not interpret silence or an unrecognized-command response as a completed write.
- Classify the target value. Keep active program-state variables under robot-program control; choose an installation variable for a value that must be supplied before the next run.
- Place the robot in the operating state required by the site's change procedure. Account for the fact that a script sent through
PrimaryInterfacecan pause the main Polyscope program. - Write the installation variable through the validated
PrimaryInterfacemethod used by the application. The evidence provides no script syntax, so take the supported statement form from the robot software or interface documentation for the installed version. - Read the installation variable back with
getVariable. Compare its type and value with the intended input before starting motion or process logic. - Start the program that consumes the installation variable. Let program logic range-check the value before applying it to a command, setpoint, or sequence decision.
Verification criteria
A successful read path needs more than one plausible response. Test a known low or false state, a known high or true state, and at least one representative numeric or structured value used by the application. Confirm that the value changes only when the underlying robot variable changes and that reconnecting the client does not leave stale data in the supervisory display.
For a write workflow, acceptance requires readback before program start and confirmation after the program consumes the installation variable. Log the requested value, dashboard readback, program state, and final value used by the program. If the main program pauses during a PrimaryInterface action, treat that pause as part of the operating sequence rather than as an incidental communication delay.
Recurring integration pitfalls
-
Using an undocumented command as a control contract: qualify
getVariableon every deployed robot software combination and fail closed when its response format is unexpected. - Confusing observation with write authority: successful reads of program and installation variables do not imply a matching Dashboard Server set command.
- Polling a transient state: latch the condition or maintain a counter when the state may disappear between requests.
- Ignoring variable scope: a currently running program variable depends on that program context; an installation variable is the better handoff for a value required at startup.
- Injecting a script during production: the resulting Polyscope program pause can interrupt the sequence. Schedule the transaction in a defined stopped-state workflow.
- Accepting without readback: compare the returned installation-variable value with the requested value before starting the consuming program.
FAQ
What happens if getVariable polls faster than the robot variable changes?
The client receives repeated samples of the same value. Timestamp and compare responses, and reduce unnecessary traffic once the polling interval is comfortably shorter than the minimum state dwell time.
What happens if a program variable changes between Dashboard Server polls?
The transition can be missed completely. Latch the event or increment a program-side counter, then read that persistent diagnostic variable with getVariable.
What happens if getVariable or the PrimaryInterface write behaves differently after a software change?
Stop using the integration for control decisions, capture the exact command, raw response, robot software identification, variable scope, and program state, then reproduce the test in a non-production condition. Escalate to the manufacturer's official support channel when readback is wrong, response behavior has changed, or the main program cannot be resumed predictably. Keep the robot in a defined safe operating state until the interface behavior is resolved.