New component: generic multiplexer

OpenCN Framework
1

Greetings everyone,

I am pleased to announce that we have recently incorporated a new component, the multiplexer, into the OpenCN framework. This versatile multiplexer allows for the selection of one vector of PINs from many.

The component can be easily customized by specifying the vector size, number of vectors, and PIN type during loading. Additionally, it is possible to load multiple multiplexers to suit your needs.

The documentation is available at the following location

Enjoy

2

Here is an example on how to use this Multiplexer component.

On a 3 axes milling machine, the target position may be generated by a Profile-Generator in Jog mode or a Path-Planner in machining (G-Code) mode. The Multiplexer is used to select the target position source to send to the Motor Controller.

The following image illustrates this use-case.

Target position selection

To comply with these requirements, the multiplexer should be set up with the following parameters:

  • Number of vectors: 2
    One vector input from the Path-Planner and one vector input from the Profile Generator
  • Size of the vector: 3
    As it is a 3 axes milling machine, a set-point is composed of 3 values
  • PINs type: float
  • Name: position
    Providing a name helps to document the use of the multiplexer (optional)

The command to load such multiplexer is the following:

./halcmd load mux name=position type=float vector_nr=2 vector_size=3

It creates the following PINs:

  • mux.position.selector
  • mux.position.vector0.input{012}
  • mux.position.vector1.input{012}
  • mux.position.output{012}

Now it is possible to connect the outputs of the Path Planer to the mux.position.vector0.input{012} PINs and the output of the Profile Generator to mux.position.vector1.input{012} PINs. The multiplexer output, mux.position.output{012} PINs, is selected with the mux.position.selector PIN.

Have a nice day
J-P

1 Like
3

Now that I can access the forum, I can ask stupid questions :smiley:
Can you please explain what would be an usecase for this component?
Also I have another potentially stupid question: I know the pin types from linuxcnc, and I assume they are the same in opencn. One thing that I am doing on my custom lathe app on top of linuxcnc: you can jog the lathe using the encoder handwheels, but when I use the joystick, I execute an MDI command. so the flow is as following: if I am in manual mode, when the joystick is moved toward Z-, I switch to MDI, and I execute an MDI command like G1 F100 G53 Z0. When the joystick comes to neutral, I do a feed inhibit + switch back to manual mode (that is done in classicladder). However I would like to do this logic inside a component. But I would like to send a string mdi command to that component. Would that be possible in any way? Or do you have a better idea for this?

4

Hi Vasi,

I’m glad that the forum is back running !

Feel free to ask any questions - no question is stupid !

We are using the Multiplexer component exactly as presented in the example presented in my previous post: In our 5 axes milling machine, the mux is used to select between the target position coming from the Path Planner (machining mode) or the Profile Generator (jogging mode). I will soon do a post which will shows our architecture for the 5 axes Milling machine.

Regarding the second question. It is a tricky one :slight_smile: . First here are some generic points regarding what is possible or not with OpenCN:

  • It could be possible to send “strings” to a component, but it is not straightforward.
  • We do not support to send MDI commands yet.
  • The joystick can be plug in the Host (same “place” as the GUI) or in the OpenCN target (Raspberry PI in general).

Based on the info, I thing the easiest way to implement the wanted feature is the following:

  • Put the joystick in the Host - It seems the more natural place :slight_smile:
  • In our app, parse the MDI command to extract the target position, speed, …
  • In the target, use the Simple PG to send the commands to drive
  • Use cmctl to set the PINs value from MDI part to target/simple PG (*cmctl is a lib wiht C++ or Python interface to control PINs from the Host).

What do you think ? We can continue the discussion about this subject in a new topic if you like.

Hope this helps
J-P

5

Hey J-P,

I have missed the email that notified me that you responded.
Thanks for taking the time to dive into my usecase.
Lets discuss this on a separate thread. I will create a separate thread with more details about what I am doing now in linuxcnc and how that would be done in OpenCN

Thanks,
Vasi

6

Hi J-P,

I have a question related to this multiplexer that is switching between the PathPlanner and ProfileGenerator, I am not sure if I understand this correctly, but I was wondering if it could solve an usecase that modern controllers like Heidenhain are capable of, but Linuxcnc is not.

Lets assume you are using a tool with indexable inserts to do some time consuming milling and while in the middle of the process you notice it sounds wierd and you wanna do the following:

  • pause the program
  • jog up the Z axis
  • stop the spindle, check the tool, change damaged inserts if needed
  • resume the milling from where left off (restart the spindle, jog the XY and then Z to their original position, then continue the program from where you left off)

If I understand your explanation correctly, I think this should be possible.
It would be just a matter of remembering the positions where you paused the program.

Also, to make the problem more complicated, lets say you need to re-touch off the tool, because maybe the tool length has changed a bit and it would need to be taken into account.

This would be a very nice addition over what the linuxcnc can do.

Let me know your thoughts on this.

Thanks,
Vasi Mihalca

7

Hi Vasi,

Nice to see you back !

For now :
This is not a supported behavior BUT it’s implementable & possible.

For the futur :
We are working on OpenCN’s thing that is needed for us regarding different research, and a pause during the milling is not in the pipeline. However, regarding milling I totally understand the need for this kind of features :slight_smile:

You are correct regarding the use of mux/simple-pg(profile generator) component, some part of the architecture is already here to support it. HOWEVER, the FSM of ocno_machining.c need to be improved in order to handle properly this behavior. Also, some small modification over feedopt(Path planner) component may be necessary.

Regading the tool length modification during milling, it would need more work on feedopt. Not to exclude the extended test that need to be done in order to ensure a proper behavior.

Hope it’s clear ! Don’t hesitate to ask question or give remark :slight_smile:

1 Like