Control of GPIO digital output while using buffered motion API

per-gron · 10 May 2021 09:47

I am working on designing and building a CNC machine for laser processing and am interested in using Granite products for driving the motors. I plan to use the SimpleMotion V2 buffered motion API for CNC motion.

In order to be able to turn on and off the laser at the right time I would like to ask if there is any way to use the SimpleMotion V2 buffered motion API to control a GPIO in a way that is synchronized with motor motion (ideally as a fourth control channel)?

If necessary I can buy another IONI or Argon drive just for this GPIO pin. If it is not possible at all to control a GPIO pin in a way that is synchronized with buffered motion, is there a way to make a GPIO pin go high exactly when buffered motion begins?

I have not yet bought the motor drives, but my planned hardware configuration is:

Drive type: IONI
Motor type: It’s an XYZ translation stage with a Brushless DC motor for the Z axis and linear motors for the X/Y axes.

Tero · 12 May 2021 10:06

Hi @per-gron!

Interesting project. Honestly, I’m using similar setup myself on my CNC router (buffered commands being used for multiaxis motion). I think IONI would be good choice for your setup.

But the answer to your actual question: yes, it is possible to control output pin thru buffered motion in syncronishm. The buffered operation of SimpleMotion V2 allows inserting any kind of commands in the buffer, not just setpoint commands.

And luckily there is a SM parameter SMP_AUX_OUTPUT_SOURCE_SELECT to control one output pin on IONI (one pin per drive, and you can drive motor with the same drive simultaneously). See:

github.com

GraniteDevices/SimpleMotionV2/blob/27d76070e5285af3862f633b1b4977a257142872/simplemotion_defs.h#L391


// SimpleMotion device specific parameter definitions start below. Note: all parameters are not available in all device types/versions. To test which are available,

// try reading them. If SMP_CMD_STATUS_INVALID_ADDR bit is being set into SMP_CUMULATIVE_STATUS on the read attempt, it means parameter doesn't exist in the target device.

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////





//choose input from SMP_DIGITAL_IN_VALUES_1 to be used as home switch.

//note: this might not have effect depending on other parameters (i.e. if output is consumed by some built-in functionality)

//written value: the index of digital input pin (i.e. GPI1=0, GPI2=1, GPI3=2, ... HSIN1=5 etc)

#define SMP_HOME_SWITCH_SOURCE_SELECT 100



//choose signal to be forwarded into aux output of drive (on IONI it is GPO5)

/*list of aux sources

 * value  	signal

 * 0		constant 0

 * 1		constant 1 (default)

 */

#define SMP_AUX_OUTPUT_SOURCE_SELECT 101



/* used only for device production testing, not recommended for normal operation, therefore not publicly documented */

#define SMP_GPIO_LOW_LEVEL_ACCESS 102

	#define SMP_GPIO_LOW_LEVEL_ACCESS_SET_PIN_MODE 0

So the trick here would be to send just stream of setpoint commands to all drives, and on-demand insert a write commands of SMP_AUX_OUTPUT_SOURCE_SELECT to the buffered stream.

However, unfortunately there is no ready-to-go example project of that (at least yet), and the buffered motion API of SM library currently only manages setpoint commands. So it might require some hacking on SM lib to add support for inserting non-setpoint commands to the buffered stream.

Let me know how this sounds!

per-gron · 13 May 2021 07:51

Thanks Tero for your response! This sounds promising.

After posting this question I found out that another requirement of this system is to use a dual encoder feedback loop (the system has rather strict accuracy and resolution requirements), and reading your documentation it seems that this is not currently supported by any of your drives. I’m afraid that this renders this discussion moot for the purposes of my current project, since I will not be able to use SimpleMotion anyway…

Tero · 14 May 2021 12:15

Sorry to hear that, and that’s true you’ll probably need something else for this purpose.

Implementing dual-loop feedback is one of ideas hanging on our wall, and I’ll add +1 to that from your feedback. The idea needs enough “votes” to get priorized to the backlog

per-gron · 6 December 2021 14:20

Here’s an update on this topic: I guess partly due to covid, it has taken a very long time for us to source the three-axis translation stage system that we’ll use, but today it was delivered. I’ve been in contact with a supplier for more expensive motor drivers that support dual loop encoders but the Swiss distributor first seemed very incompetent in our phone call (confused analog input with outputs, made a few statements that contradict datasheet information and could not answer any of my questions that were not already easy to find on the website), and then proceeded to not get back to me as promised. :-/

So we will very soon be placing an order for Granite drives. I think we will survive without the dual encoder loop for now as it’s only in the Z axis which has inherently relaxed requirements due to the elongated laser focal point.

I’m excited about using your products!