the workspaces are internal feature so without access to source code there is no way to manipulate it.
one can of course create own code that does similar but not exactly the same. the problem is that code need to be processed. in other words it need to run in some interpreter. but KSS workspaces always work - even when no interpreter is active, because this is processed internally. you can test this by deselecting robot program and all submits and then jog robot manually - built in workspaces will still work.
the other limitation is performance or reaction time. this depends on performance of the interpreter. if used interpreter is busy with other things, it will be slow to get to your code that evaluates additional spaces. during that time robot may move more than you like.
aside from such limitations, yes you can make your own variant...
also, one can create own state machine that reconfigures existing workspaces. this means you still only have 8 spaces but they are used differently depending on what robot program does.
btw KSS has 24 workspaces:
8 Axis specific
8 Cartesian,
8 Cylindrical
Cylindrical spaces do not show up in HMI configuration plugin but they are functional.
The key advantage of using the system Workspaces is that they work regardless of whether the robot is running or not. Even if both the Robot and Submit interpreters are halted, the WorkSpace will still function.
Roll-your-own emulations of Workspaces are possible, but will suffer from this limitation. For example, creating your own equivalent of an axis-specific Workspace in the SPS is possible, but if the SPS is halted for any reason, whatever signal you have associated to that ersatz Workspace will not update. So you'll need to keep this in mind.
It is also possible to change the parameters of a system Workspace from inside your program. So if your process allows it, you might rewrite the dimensions of a Workspace depending on what part of your program(s) is running. Obviously, this brings some risk with it, so your programs would have to include checks to ensure your Workspace is not set for Program A while running Program B.
Would it not be possible to just enlarge the array of Workspaces?
Would it not be possible to just enlarge the array of Workspaces?
No. They are system variables, not user-generated variables.
...well, I've never actually tried it, but I would be amazed if editing those arrays actually worked.
For one thing, multiple arrays in multiple files ($MACHINE.DAT and $CUSTOM.DAT) would have to be edited. The standard set of Workspace-related variables are implicitly linked by KSS, but there's no way to tell KSS to add more linkages. The $WORKSTATE signals are defined in $MACHINE.DAT (which, the last time I tried, could not have lines added or removed, only values could be altered), and $WORKSTATE1 is implicitly linked to $WORKSPACE[1] (which is defined in $CUSTOM.DAT). Not to mention the implicit link to $WORKSPACE_NAME1, which is a CHAR array containing the string name of the Workspace.
You need to be a member in order to leave a comment
