Hardware and Signal Settings¶

The Hardware and Signal Settings subpage allows for the configuration of advanced options for the palletizer application. In order to navigate to the Hardware and Signal Settings subpages, click on “Hardware Settings” or “Signal Settings” at the bottom of the Settings page.

Attention

Ensure you restart the snap package after changing any developer setting. Do so by running sudo snap restart jacobi-palletizer.

Hardware Settings¶

System Name¶

The system name uniquely identifies your Jacobi Palletizer configuration. It is used primarily for internal processes and logging purposes, so there is no need for user intervention or concern.

Hardware¶

In this section, you can:

  • Choose between ‘Simulated’ or ‘Real’ for the robot driver and controller, defining how the system will operate in either a testing or real-life environment.

  • Specify the robot cell.

  • Set the robot host IP Address to establish the network connection.

  • Define pallet names. Misdefining these is a common source of bugs.

Process¶

In this section, you can configure the following settings:

  • Automatic Clear Pallet: Whether to clear the pallet if it’s not present for a specified number of seconds. When this option is checked, you can configure the duration using Clear Pallet Duration.

  • Check Pressure Sensor: Whether to check the pressure sensor and trigger a fault if necessary.

  • Conveyor Control by PLC: Whether the conveyor is controlled using a PLC or robot controller

  • Fault on Area Scanner Triggered: Whether to trigger a fault if the area scanner is activated.

  • Gripper has Blowoff: Whether to enable blowoff for the gripper to allow for faster release.

  • Require Heartbeat Ping: Whether to require a heartbeat ping to ensure the system is responsive.

  • Sleep after Vacuum Change: The time to sleep after switching the vacuum on or off.

Signal Settings¶

To ensure the successful operation of the Jacobi Palletizer, it’s essential to configure signals for seamless integration with hardware peripherals, such as sensors and safety components. Below is a step-by-step guide on how to set up these signals for the regular workflow of a palletizer.

Tip

Different robots handle signal aliases differently, and the guide below may not apply to all robot models when it comes to signal naming. For model-specific guidance on setting robot aliases, use the tabs along the guide to switch to your robot model of choice for our conventions with specific robot models.

Tip

Be wary that signal names are being spelled correctly in the Jacobi Settings UI. Note that not putting a signal name will disable the signal - the palletizer will assume that there is no need for that signal and operate independently of it to the best of its ability. For example, if no area_scanner_slowdown signal is provided, the robot will never reduce its speed dynamically during a palletizing motion. If no box_at_pick signal is provided, the robot will always assume that it has picked up a box correctly and continue palletizing.

Pallet Sensors¶

The robot needs to know what pallets are present for it to place objects on. To this end, visual sensors (for example, IR sensors) are placed within a cell to detect if a pallet is present or absent. These sensors can be connected either to a PLC or directly to the robot controller, where the information they relay can be saved to a signal variable you can name. When this name is passed into the pallet_present field in Signal Settings, the Jacobi Palletizer software gets access to the information relayed by these sensors.

The pallet_present signals, if activated, signal to the palletizer that the corresponding named pallet is present and available to palletize boxes on. The names for each pallet should match with the associated Jacobi Studio Project, and specified in the hardware settings.

If a pallet is removed or identified as ‘not present’ while the robot is attempting to place a box on it, the robot immediately stops and reports a Fault, following which it has to be sent back to Home to restart palletizing operation. In all other cases where a pallet is removed (e.g. a pallet the robot is not working on is removed, or the pallet is removed after it has just placed a box and is moving back to pick up a new box), the robot will continue palletizing on the next available pallet.

Jacobi does not currently support custom signal aliases for UR robots. Instead, we use the following convention to read to and write from signal I/O. We use digital_in[0] to digital_in[7] to address digital input signals, and config_in[0] to config_in[7] to address configuration input signals. By mapping the pallet sensors to any of these input signals, we can read from these aliases to get the desired value.

To test if the pallet_present signal is set up correctly, remove a pallet and check that the corresponding named pallet is reflected as absent in the UI. Observe the top right corner of the Dashboard, as well as as the status indicators next to each pallet in the pallet visualization.

Pallet Present Pallet Absent

E-Stop¶

While pressing a robot’s Emergency Stop (E-Stop) will stop a robot physically with or without the Jacobi Palletizer, it is important for our software to be aware of what, if any, E-Stops are pressed so that we can reflect the correct and accurate state of the robot at all times in our HMI.

The state of the E-Stop can be configured as a signal variable either via a PLC or directly to the robot controller. When this variable is passed into the Jacobi Settings e_stop signal field, the Jacobi Palletizer will be informed appropriately.

The e_stop signals, if activated, signal to the palletizer that the corresponding E-Stop has been pressed. The robot will cease operation and be in a Faulted state until the E-Stop is disarmed. To test if the e_stop signal is set up correctly, press an E-Stop and observe the dashboard. The UI on the top right of the dashboard will reflect which E-Stop is correctly pressed.

Tip

Be mindful of the ‘active on’ toggle in the UI. Some signals are often inverted for various reasons (for example, safety signals like E-Stops are often inverted) - in which case you’d want Jacobi to acknowledge that they’re ‘active’ on 0, as opposed to on 1, which is the default.

Jacobi does not currently support custom signal aliases for UR robots. Instead, we use the following convention to read to and write from signal I/O. We use digital_in[0] to digital_in[7] to address digital input signals, and config_in[0] to config_in[7] to address configuration input signals. By mapping the E-stop to any of these input signals, we can read from these aliases to get the desired value.

E-Stop

Area Scanner¶

A palletizing robot is often making a lot of motions at very fast speeds. Particularly in industrial settings, it is important that high speeds of operation are balanced against the need for safety - area scanners are one such sensor that accomplish this task.

By detecting the presence of nearby humans and obstacles, area scanners can inform a palletizing robot about objects to worry about in its vicinity, having it slow down or even stop if they are too close for comfort. Area scanners can relay information to a robot, either directly to the robot controller or via a PLC, to a signal variable with a name of your choosing. Passing this name into the Jacobi Palletizer allows our software to correctly instruct the robot to slow down or stop as needed.

The area_scanner signals, if activated, signal to the palletizer that the corresponding named area scanner detects something within its visual range. The names for each area scanner will correspond with the ones specified on the hardware settings page.

There are two classes of area_scanner signal:

  1. area_scanner_stop signals: When the palletizer receives this signal, it throws a fault and the palletizing operation stops.

  2. area_scanner_slowdown signals: When the palletizer receives this signal, the robot slows down palletizing operation to 20% of its normal speed.

A single area scanner is capable of sending multiple distinct signals, each configured to detect when someone or something enters within one of several predefined areas in space. The area scanner should be placed outside the robot’s range of motion so it does not trigger the scanner.

If that is not possible due to cell configuration layouts, signal logic can be used alongside our provided signal outputs jacobi_palletizing_pallet, which lets the receiver of the signal know that a given pallet is being worked on. This information can be used in conjunction with area scanner signals to avoid false positive triggers of the area scanner stopping the robot prematurely.

Jacobi does not currently support custom signal aliases for UR robots. Instead, we use the following convention to read to and write from signal I/O. We use digital_in[0] to digital_in[7] to address digital input signals, and config_in[0] to config_in[7] to address configuration input signals. By mapping the area scanner to any of these input signals, we can read from these aliases to get the desired value.

Example: The detection of an obstacle to stop the robot is linked to the signal named is linked to the digital signal numbered 7. We would define in the signal settings as follows.

Area Scanner Stop

To test if the area scanner signal is set up correctly, follow the steps as below.

  1. For the area_scanner_slowdown signal, once activated during a palletizing sequence, the HMI will display a popup on the top right as in the image below.

Area Scanner Slowdown

  1. For the area_scanner_stop signal, once activated during a palletizing signal, the HMI will throw a fault and stop robot motions, as in the image below. To ensure this, you also need to go to Settings > Hardware Settings and turn on the configuration option for ‘Fault on Area Scanner Triggered’.

Area Scanner Stop

Light Curtain¶

As with the area scanners, the light curtains are another safeguard in making sure that safety is maintained at all times when working around palletizing robots. Light curtains trigger when something crosses them, allowing for simple constructions that can, for example, stop the robot when a person walks into the palletizing environment.

Light curtains, like the aforementioned sensors, can be configured directly within a robot controller or via a PLC, with their information relayed to a signal variable of your choice. Passing this into the light_curtain signals allows Jacobi Palletizer to reflect this and show Faults when the light curtain is broken by a person or obstacle.

The light_curtain signals, if activated, signal to the palletizer that the corresponding named light scanner detects something breaking the light curtain. The names for each area scanner should match with the associated Jacobi Studio Project, and specified in the hardware settings (link to the hardware settings page).

If the light curtain signal is triggered for any reason, the robot will stop operation and be in a Faulted state, following which it needs to be sent back to home to restart palletizing.

If it is necessary for the robot to pass through the light curtain, the signal logic needs to be revised before Jacobi receives information from the light curtains, to prevent the robot from triggering the curtain on its own and stopping itself.

Jacobi does not currently support custom signal aliases for UR robots. Instead, we use the following convention to read to and write from signal I/O. We use digital_in[0] to digital_in[7] to address digital input signals, and config_in[0] to config_in[7] to address configuration input signals. By mapping the light curtain to any of these input signals, we can read from these aliases to get the desired value.

Example: The detection of an obstacle in the light curtain LightCurtain to stop the robot is linked to the configuration signal numbered 3. We would define in the signal settigns as follows.

Light Curtain Signal

To test if the light curtain signal is set up correctly, start palletizing and then trigger the light curtain. The robot should enter a Faulted state as below.

Light Curtain

Conveyor Sensor¶

The Jacobi Palletizer plans box picking with user configuration and cycle time in mind, with the ability to switch between picking one box at a time and two boxes at once (single pick vs. double pick). It is necessary that the Palletizer knows when the boxes are available to pick and that the conveyor sends the correct number of boxes onto the pick point at the conveyor.

A visual sensor can be used to identify when a box is ready to be picked (much like ones used in the pallet sensing) - this sensor can relay information directly to the robot controller or via a PLC to a signal variable that the Jacobi Palletizer can access if given the correct name.

The box_at_pick signal, if activated, signals to the palletizer that there is a box ready to pick on the conveyor. If the robot is at the wait position above the pick position, it will move in an attempt to pick up the box(es) that triggered this signal.

To test this signal, start a palletizing operation without any boxes on the conveyor. The robot should wait above the conveyor, anticipating the arrival of a box. Trigger the sensor with one or more boxes - the robot should then begin palletizing operations.

Conveyor Programming

If your cell needs the conveyor to be programmed to send boxes to the cell, Jacobi provides output signals that you can use to guide how and when you activate your conveyor motors (for example, for the singulation of boxes to avoid them pressing against each other when they are being picked up by the robot, or for alternating single/double pick scenarios).

  1. jacobi_pre_pick - This output signal lets the receiver of the signal know when the robot is waiting, before it gets to pick one or more boxes.

  2. jacobi_double_pick - This output signal lets the receiver of the signal know if the next set of boxes to be picked up is a double pick or not.

  3. jacobi_box_width: The width of the box in the current palletizing setup, corresponding to how it was set up in its associated Jacobi Palletizing Setup page.

  4. jacobi_box_length: The length of the box in the current palletizing setup, corresponding to how it was set up in its associated Jacobi Palletizing Setup page.

  5. jacobi_box_height: The height of the box in the current palletizing setup, corresponding to how it was set up in its associated Jacobi Palletizing Setup page.

Jacobi does not currently support custom signal aliases for UR robots. Instead, we use the following convention to read to and write from signal I/O. We use digital_out[0] to digital_out[7] to address digital output signals. We use config_out[0] to config_out[7] to address configuration output signals.

Gripper Sensors¶

At the heart of the palletizing operation is the gripper, which the Jacobi Palletizer software communicates with frequently. The grippers are set up and connected with the robot controller or PLC, and can communicate information about whether or not it is exerting suction to pick up a box, if it’s identified that it has a hold on something, etc. This information can be codified as signal variables that can be then passed into our Jacobi Palletizer so that we can control it throughout the robot palletizing.

There are two signals associated with the behavior of the gripper throughout a palletizing sequence.

The jacobi_vacuum_on signal, if activated, signals from the palletizer to the gripper to turn on the vacuum of the gripper to pick up one or more objects.

The configuration of this signal can be tested in the dashboard under the Developer Helpers drop-down at the bottom of the screen. Use the Start Suction and Stop Suction buttons ensure that the gripper is responding to the palletizer trying to communicate with it. Observe that if the vacuum is turned on, the palletizer will not allow you to start palletizing until turned off, with the popup in the top right.

Gripper Suction

The vacuum_sensors signal, if activated, signals the palletizer whether or not the gripper was able to successfully pick up and hold an object.

If the signal reports that that the gripper was unable to pick up a box, it will attempt to pick up the box two more times before stopping palletizing and entering a Faulted state.

In other scenarios where the signal reports that the gripper is not holding a box (e.g. during palletizing, when the robot is moving to place a box), the robot stops immediately and enters the Faulted state. In both these cases, the robot needs to be sent back to home for palletizing to restart from where it last left off.

The vacuum_sensors signal is typically achieved through pressure sensors in the gripper that report if the pressure and suction is beyond a certain threshold. Another common alternative is through visual sensors that monitor the presence of an object under the gripper. In either case, the signal can be tested as triggering the box_at_pick signal with a small obstacle that cannot be picked up by the gripper. This will make the palletizer believe that a box is ready on the conveyor to be picked up. If the sensors signal is operating as expected, the robot will simply attempt to pick up the non-existent box a few times before reporting a Fault.

Box At Pick

Jacobi does not currently support custom signal aliases for UR robots. Instead, we use the following convention to read to and write from signal I/O. We use tool_in[0] to tool_in[1] to address tool input signals, and tool_out[0] to tool_out[1] to address tool output signals. These signals can be used to read information from the gripper, like vacuum and blow-off.

Safety Lights and Buzzers¶

Jacobi provides several output signals that can be used to program lights or audible alarms to inform operators of various states in the palletizing cell.

  1. jacobi_palletizing_pallet - A signal that identifies if a given pallet is the active pallet that the robot is palletizing on or not.

  2. pallet_full - A signal that identifies if, for a given pallet, that pallet has finished palletizing and has all its boxes.

  3. jacobi_system_state - A signal that identifies the state of the robot in its operation. This state corresponds with what can be observed on the Dashboard UI.

  4. jacobi_error_pallet - A signal that identifies, if, for a given pallet, there is a Fault the robot is facing that is either a general issue or specific to that pallet.

Jacobi does not currently support custom signal aliases for UR robots. Instead, we use the following convention to read to and write from signal I/O. We use digital_out[0] to digital_out[7] to address digital output signals. We use config_out[0] to config_out[7] to address configuration output signals.