I’ve been an Android Developer for the past 10 years, but my passion is metal working & cnc machines. I have a home shop with a lathe & mill, both of them running linuxcnc. I’ve made my custom controllers for both of them, because I’ve wanted to adapt them more for touch screen functionality.
The controller for the mill is written on top of QtPyVcp framework, but after about 15 years of OOP, python’s mess was not my cup of tea. Therefore my lathe controller is written in kotlin, (a fancier java) and along with compose UI framework that is multiplatform, have made a much nicer coding and UI/UX experience. I’ve started from a linuxcnc java UI found on github then added the rest of the JNI functionality needed to call the library from java.
I have some questions about this OpenCN:
can it be configured to work with lathes that have only two axes?
is spindle sync still working after the changes that were made?
can it be consumed from a higher level language other than python? Is it the same NML interface that linuxcnc uses?
thanks a lot for your post, and welcome as a potential OpenCN developer !
The transition from LinuxCNC to OpenCN is important.
The most important points are :
Modern real time framework (no obsolete RTAI, no poor real-time RT-preempt, but a new Xenomai based AMP architecture with dedicated CPU cores, very recent Linux kernel).
Advanced trajectory planning algorithms with jerk control
Only EtherCAT field bus (no other real time bus, no MESA card supported)
Concerning your questions :
In principle, lathes with only 2 axes are possible
The spindles we use today are controlled in speed, not in position. But it should be possible to view the spindle as an axis to be synchronized.
I’ll come back to this question later.
We’ll have an OpenCN meeting this friday.
I’ll keep you updated,
Concerning the third point, any programming language can be used provided that you can access rely on tcp/ip connections.
We have not followed LinuxCNC along the GUI interactions. Currently, we are using Qt with rcp based communication between the GUI (running on external PC) and the target, as you can find in agency/usr/ host/user_gui/ directory.
As Raoul said, OpenCN can work in 2 axes. But we currently are on the test phase of a more generic version of the different components.
About the spindle, OpenCN only informs when the spindle can be enabled. As specific code has to be mode to handle this spindle for a specific machine.
The GUI is running on an external / Host PC. The current GUI is communicated this GUI thought a RPC client/server (we used Captain Proto). A C++& a python APIs is available.
A generic TCP client/server is also available.
I am really excited about the software changes that you have made. It looks very promising and indeed its far ahead of what linuxcnc is now, especially the jerk control.
For the lathes, we need G33 to work and G76 which relies on G33. Basically we need to be able to sync the Z axis with the rotation of the spindle in order to have threading.
For a mill, this G33.1 is used when rigid tapping, there also spindle synchronization is needed.
You’ve mentioned that you have a meeting on friday…I know it might be a stupid question, but is there any chance that I could join this meeting and hear what’s being discussed?
I am really curious about all the internals of OpenCN and any cnc controller in general.
Hi Vasi,
our friday meetings are specific project meetings.
I will contact you by private mail in order to fix a Teams videoconference with us.
best regards,
This is a late follow up of our discussion we had on Teams.
As I said I don’t have experience on C++ but I am willing to learn. I am now searching for a course to enroll and try to develop my C++ skills.
However, if its possible, I would want a developer account so that I can review pull requests. That might help me to get more familiar with the code.
This is my personal github profile: 85vmh · GitHub
I’ve visited IMTS 2 weeks ago, and after seeing other controllers, I really think this one could have a great potential.
Thanks for your message. You’ve been granted with developer privileges.
I sent you the grant by e-mail.
We plan to move to github in a couple of weeks to have a better visibility.
From what I saw, the OpenCN project uses rpc and proto for communication, have you considered gRPC? It’s an open source library from Google that does exactly this.
I’m planing to use the OpenCN rpc in my JVM app and I’m not sure which library to use. I think going with gRPC will help because there’s a lot of client and server implementations available and a lot of support for it(I’m pretty sure there are open source code generation plugins).
We have not considered gRPC so far, since we were more concerned with a simple lightweight message encoding and protocol. I don’t know it myelf, but it may worthwhile to consider it for Java app. I guess Jean-Pierre may have another vision and experience, but it is in vacation until November 1st. Anyway, plese tell us about your investigations.
I mostly use Bazel now and it supports proto buffs very easily(generating code for different languages)
Example: Protocol Buffers in Bazel - Bazel
Bazel can also be used to create C++ applications, once you get used to it, it’s better than CMake. I don’t write C++ myself, but gRPC generates some code using bazel(stubs to implement).
After going with gRPC it’s really easy for me to just take the service files and generate the client in java(and other languages).
Sorry for spam, I can’t post more links in a single message.
After that, I want to create a GUI for the CNC part using kotlin multiplatform, so that I can have different kinds of clients(ios, android, web, desktop).
Right now our app uses JNI to communicate with LinuxCNC, I was thinking of a way to move that to some network communication, but seemed like a lot of work, if OpenCNC provides that, it will make things far easier for us to make our app multiplatform.
Well, if your Java or Kotlin app uses network sockets, I guess you can communicate with the other end remotely via TCP/IP and this should not be an issue.
Captain Proto was selected mainly because it was an improvement over Proto Buff. It was also used in another internal project at REDS.
I don’t remember why we did not select gRPC…
Currently we have only support PINs read-write in C/C++ and python (doc)
As Daniel said, we are currently not considering changing tools for communication. But, we are not closed to it, if there are good reasons.
We also has a support for TCP client / server (link)