Example 2 - DDE Job Parameters

Open up DDE and copy in the following:

var my_dex = dexter0
new Job({
	name: "Example_2",
    robot: Dexter.my_dex,
    keep_history: true,
    show_instructions: true,
    inter_do_item_dur: 0.01,
    user_data: {
    	my_var: 10
    },
    do_list: [
    	Dexter.move_all_joints([0, 0, 0, 0, 0]),
        Dexter.move_all_joints([30, 0, 0, 0, 0]),
        Dexter.move_all_joints([30, 30, 0, 0, 0]),
        Dexter.move_all_joints([30, 30, 30, 0, 0]),
        Dexter.move_all_joints([0, 0, 0, 0, 0]),
        Dexter.empty_instruction_queue(),
        function(){
    		out(this.user_data.my_var)
		}
    ]
})

/*

To Run:
Eval and click the Job button to run the Job.

Notice:
-The similarities to Example 1
-The differences to Example 1 while running the Job
-The line of code above the Job definition

Challenge:

Edit the above code in order to do the following:
a. Not record the sent Instructions
b. Turn off the display of the progress bar
c. Have a 1 second delay between instructions
d. Change the name of the robot to "Bob"
e. Add a user_data variable 'my_array' that has a value of [1, 2, 3]
(while keeping 'my_var')

Change the above to meet the challenges and then save the file as Example2.dde and upload it. 

Explanation:

Example 2 is showing the additional parameters that can be passed into a Job definition.
These parameters will change the Job's behavior and are mostly optional.
Their defaults are the following:

robot: Dexter.dexter0,
keep_history: true,
show_instructions: true,
inter_do_item_dur: 0.01,
user_data: {},

'robot' defines which robot that Job's Instructions, like move_all_joints, are sent to.
It is defaulted to Dexter.dexter0.
Dexter.dexter0 is defined in your dde_init.js file located directly under dde_apps.
Haddington Dynamics ships all new robots with a static IP address of 192.168.1.142.
You cannot have two devices, including two Dexters, on the same IP address.
To change Dexter's IP address, see our github wiki:
https://github.com/HaddingtonDynamics/Dexter/wiki/Dexter-Networking

To create a new Dexter instance:

new Dexter({name: "my_dex2", ip_address: "192.168.1.143"})

This new Dexter instance will show up under the 'Dexter' class:

Dexter.my_dex2

Eval the above line and see what it returns.

'keep_history' is the Job parameter that controls whether or not the Job records every sent instruction.
When you Eval this file you'll see that the Job gets Inspected in the Output pane, with the following header:
INSPECTing A Job named: Example_2
After the Job has been run you can click the 'Refresh' button (left of header)
Then click on 'more...', then click the drop-down arrow next to 'sent_instructions'
This will display a table of sent instructions.
This is a useful debugging tool for seeing what and when instructions are sent.
'keep_history' is defaulted to true so instructions will normally be recorded.
This can cause problems if a large amount instructions are being sent (>1000).
These problems include:
- increased time between instructions
- large intermittent delays due to random garbage collection
- sluggish behavior of the DDE window

'show_instructions' is the Job parameter that controls the progress bar.
The progress bar will be displayed with a value of 'true' and hidden with a value of 'false'.

'inter_do_item_dur' is the Job parameter that controls the time delay between Instructions.
You can think of inter_do_item_dur as a kind of a frame rate (or 1/fr).
All the DDE functions that use units assume everything is in SI units, and likewise inter_do_item_dur uses seconds.
This is the delay in between Instructions so it does not include the time it takes for the Instruction to complete.
inter_do_item_dur can be set to 0 for the minimum time between Instructions.
This may be critical for smooth continuous Dexter motion between many Instructions.
Setting it to 0 may cause issues with other processes happening in parallel, such as running another Dexter, print statements, GUI button clicks.

'user_data' is a unique Job parameter that is a place for the user to put
whatever they want: variables, functions, arrays etc.
user_data must be set to a literal object i.e. {}
It is especially useful for manipulating data between Instructions while a Job is running.
When a Job is started, the variables will be re-initiated to the values
that are in the Job's definition under user_data.
The values can be accessed by an Instruction on a do list with the following:

this.user_data.[insert variable name here]

The alternative to using user_data is to use global variables at top level:

var my_val = 10

Then you can access if by typing 'my_val' instead of 'this.user_data.my_val'.
This may seem like a simpler architecture but it creates two problems:
-The variables will not re-initiated when the Job button is clicked multiple times.
-May have name collisions with other code, especially when you start loading in multiple files without seeing them.

The Job parameter defaults are the best for debugging but not necessarily the best for performance.
These are the recommended values for best performance:

keep_history: false
show_instructions: false
inter_do_item_dur: 0

The Job parameters included in the example are just the generally useful ones.
There are more Job parameters not mentioned in the example.
To see the complete set, place the cursor on the word 'Job'.
You can also then click the blue underlined word Job in the Output pane for the documentation on 'Job' and Job parameters.