Java UI for linuxcnc

> I would rather try to sort out the rendering part. I only need 2D rendering since I am using this software only for lathe

Hm, I don't understand, where you have a problem. 2D-graphic is the "trivial" part. I would use swing, which provides everything you need. I don't know, what kotlin provides.

I had some troubles to find a library that supported 3D-graphics. Most libraries where outdated and/or abandoned ...
I finally decided to use jmonkey, but I had to write graphic primitives for jmonkey on my own.

Thanks for reaching back to me!
Kotlin is basically Java, so I can use any library that Swing can use.
For now I have integrated VTK but what I don't know, is how to get the data about what lines & arcs I need to draw. In qtpyvcp library that is done by calling "gcode.calc_extents" and "gcode.arc_to_segments" functions. By those exist only in python.
This week I am quarantined so I would wanna work more on my app.
Please help me sorting out this, I obviously don't have the experience that you do so I am even willing to pay for your consultancy.

> I am even willing to pay for your consultancy.

Never mind! I'm not looking for job and I have everything I want - I'm coding just for fun.

> For now I have integrated VTK

Not bad. Should do the job. Even with 3D ...

> what I don't know, is how to get the data about what lines & arcs I need to draw

Well, that's where linuxcnc becomes ugly and stupid
I tried to use the interpreter executable (provided by linuxcnc), but imperial units are hardcoded and lot of things don't work as if you use the interpreter internally. But for using interpreter internally, you have to code very much native code.
Interpreter of linuxcnc is perverted - you have to parse ini-files, parameter-files and tool table all by yourself and send the data to interpreter. Well, you don't send data - you have to provide callbacks which get called by interpreter. That leads to ridiculous calls, like interpreter asking 1000 times for tool data - even if you have 5 tools only, or you have to provide saved position or coordinate system offsets - everything you never wanted to care about - you have to. And regarding to work paths - interpreter is calling python interpreter, which then executes a c-native function. Very cute :/
... and as you can't build an interpreter without python, you end up with a kotlin application, with native c-code and imported python interpreter which you never want to use ...
... and with providing thousands of c-callbacks you can't be sure, that you got the same setup than backend is using.
If you start fiddling with linuxcnc interpreter you have to dive deep into linuxcnc source code and you won't stop banging your head against the wall ...

You can have a look at my Qt-Project , where I tried to satisfy interpreter with all the callbacks.
As said, I'm not sure, that I got the same output than linuxcnc backend sends to taskmanager. Actually my preview does not look bad, but ...

A more elegant way is using a nice interpreter like grotius does in his hal core project. With that interpreter you have to code less native code. You could also write your own interpreter. Not as ugly as coding all the required callbacks for linuxcnc interpreter.
Anyway - a lot of testing is required to get almoust the same result than linuxcnc produces.

May be there exists a gcode interpreter library for java - didn't search for that.
The drawback of native interpreter - you permanently switch between C and java - I guess that may decrease performance. Well, executing linuxcnc interpreter executable leads to much poorer performance, as you have to parse text-output from another process ...





 

It is not clear to me yet how did you handled the displaying of the gcode in your JCNCScreen.
What interpreter are you using to get the data that you need to render? 
Would the same approach work for me? 
The way I understand this is the following: 
- interpreter takes the gcode file, and based on the ini, tbl files it inteprets the file and produces a set of lines and arcs that can be drawn. 
- using the position info from the status channel, you render the tool inside that plotting at the correct coordinates.
- by not using exactly the same interpreter as linuxcnc does internally, we can't be sure that what we see rendered is what will actually look like.
- if the linuxcnc standalone interpreter would work, is that the same with the internal interpreter?

Sorry if I am asking silly questions, but just by reading your comments I can clearly see that you have waay more knowledge depth that I can imagine for now.

I have noticed that the stand alone linuxcnc interpreter documentation was updated in 31th of january this year, so literally yesterday.
Is this the standalone interpreter that you were trying to use and has hardcoded units?
linuxcnc.org/docs/html/code/rs274.html

I have not yet pulled & built the last sources of linuxcnc, but I've made a test run for the standalone interpreter and I got the result in the screenshot below. Are you using something similar to render your plot? Can you please give more details about that?
 

> It is not clear to me yet how did you handled the displaying of the gcode in your JCNCScreen.
> What interpreter are you using to get the data that you need to render? 
> Would the same approach work for me? 

As said, in the java app I use the provided interpreter executable from linuxcnc. Similar commandline than your log.
I started the interpreter in a new process and parsed the textdata from pipe.
I struggled several times with different output between axis (my reference) and my code. Then I found out, that the standalone interpreter is different from the one that is used by backend (taskmanager).

Just compare src/emc/sai/saicanon.cc with src/emc/task/emccanon.cc

I had to realize, that standalone interpreter is hardcoded to imperial units. If your machine works with imperial units, that might work for you. I'm used to mm, so position calculations where wrong. Another difference is, you don't get the line number in interpreter output. But my progress calculation during auto processing is based on line numbers.
Therefore I had to patch gcode input with sequential numbers N# - which the interpreter tells in output. Some commands lead to multiple steps with the same line number.

You can have a look at class RS274Reader to see, whether it might be useful for you.

I stopped frustrated development of my java app, when I realized, that there's too much missing in output from provided executable. That was one reason, why I started my Qt project.

In the beginning I had both paths available: using standalone interpreter and parse the output or create an internal instance of interpreter. The differences where too big so I stopped using standalone interpreter. Additionally the parsing of the textoutput from standalone executable was about 100 times slower, than internal interpreter.
The drawback of the internal interpreter - I had to care for all the data and function callbacks to satisfy interpreter.
That was another period of frustration and headbanging - but meanwhile it works. As far as I can validate it.
In the mean time FalconView has more functionality than the JCNCScreen.

> - using the position info from the status channel, you render the tool inside that plotting at the correct coordinates.

No! I don't do that.
I create the graphic objects on parsing output from interpreter, so when the interpreter is ready, my workpath is already painted to canvas.
When the automatic processing runs, I select the graphic objects based on the line number. Only the tool is advanced based on the position from status area.

> I have noticed that the stand alone linuxcnc interpreter documentation was updated in 31th of january this year,
> so literally yesterday.

Afaik actually the whole documentation is revised as they changed the translation base. But I can't say anything about status.

> just by reading your comments I can clearly see that you have waay more knowledge depth that I can imagine for now.

Well, I started with a clone of saicanon, where I added debug output to every callback, the interpreter uses. I could not believe the debug output, so I started to watch progress with debugger. Guess that was the biggest disappointment for me since I started using linuxcnc.