How would you design a real time application for cnc control in c / c++ ???

@Grotius ... wow I'm impressed. You've really spent a lot of time reading the Lcnc code and creating the right .h files for this interface. Bravo great job. It deserves a reward.
In the last 6 years I have never found the time to do this .... very well done. In my attempts I was getting too many disconnections from nml .... now that I see what you have done I understand that it was quite normal that I received them. But I am merciful to myself, I have many ideas, but I am not a good programmer and I often get lost in a glass of water.

Thanks again.

@Btk,

Thanks buddy for your kind words.

If you sent c++ command's trough the halui interface, it works just fine. In my opinion the best way to start with.
You can see i use the existing interface of the c++ halcommand source code. So in fact you can do every halcommand
though c++ in this way, or trough a c++ system(" ") command if you have more time.

If you use c++ with the nml channel (commands), the channel must be destructed or closed in the right way.
In my code sample that is not properly done. With every nml command i create a new channel.
After a few minutes and many nml commands some kind of overflow happens and lcnc
becomes slow. Keep that in the mind.

I have many ideas, but I am not a good programmer and I often get lost in a glass of water.
Me too. Today i was starting to make my first mobile app. After multiple hours i now got my first c++ app working on my android phone.
A few day's ago i made my first webserver and webclient chatprogram trough a onion proxy.
This worked in a few hours, thanks to some github qt examples. I came to the conclusion that the chatprogram is really invisible, even
HexChat could not see it, because HexChat uses channels and my app not. Every day you can learn something different, if you
have the time to do it.

If you use the chatprogram (tcp based) on your mobile phone, you can control lcnc trough a onion webserver. This is safer then a telnet interface with in fact an open backdoor. Also no port forwarding is required and it is invisible.

@ Grotius ... in fact two or three years ago I thought of a java / android application that I ran on my phone and I sent some commands halui using modbus on bluehoot and my modbus component for hal .... I think I published it here years ago. ... it was crap but it worked. I had also used speech recognition to call "stop" as an emergency stop. Google Stop is a common command recognized in practically every language. However I live in Italy and here the UNI and IEC regulations are in command .... all bluethoot commands are not allowed here due to security and in addition android does not even have icons certified for safety so that you cannot use even an emergency icon -opensources.pnf but you have to use default icons. Finally, the wireless communication of the commands of a machine must be certified separately, especially if it is the start or stop of a milling machinery or a robot. All this puts big brakes on the fancy flights of the imagination. Nowadays, commands and security leave few spaces .... ethercat, canOpen FD, profinet and other 2/3 that we all know .... unfortunately only the first two are for Lcnc and Qt. If then soon on opcUA they will also allow security commands .... well then it will be better .... but for now machines and commands from mobile phones are not a great idea ... at least in my part .... I don't know how works on the other side of the ocean but safety regulations are usually never as tight as ours and luckily they always allow something more.

anyway I forked your project .... the idea is to use only halui commands .... about nml .... it's not just an overflow problem .... there's more ... if run the classic example of positon logger running a 5 axis gcode with thousands of do / while cycles, the position logger runs for hours (on qt I ran it on a separate thread from the main) .... but if sometimes pause and then run ..... only then is there disconnection. I think it depends on the propagation of commands. I have not read the code well .... but I know the programmers .... those certainly have privileged the commands coming from the python flow of axis the historical gui .... in fact all the other gui, while working very well are not " granite "like axis gui. nml is certainly the most "mistreated". I think the misconception is that axis gui is the official Lcnc gui ..... while for correctness it should be nml the core of every gui or halui too. In this way every gui would have equal dignity. However I understand very well that it is easier to write a code with "import linuxcnc" on the first line and then a series of simple commands. Just to reinforce the concept not even halui as an interface is "granitic" as axis gui. This speaks volumes. If halui had a complete and well tested tools of commands and states, that could be the official gui .... even in this way all the gui that used halui as a base would have equal dignity.

But you have to be satisfied .... what is on Lcnc is really a lot and thanking the developers is never enough.

thanks Again
bkt

So, I've downloaded this again: github.com/grotius-cnc/Skynet_Robot_Cont.../releases/tag/1.0.15
And have been able to build it in QT without error when I run it the gui starts but as soon a I click on "load robot model" or "reset joints" the gui crashes with error .."/skynet crashed".

The problem of being able to switch between trivial and coordinated kinematics using KDL will also need to be adressed.
Just give me a detailled practical example of the problem. Then i can think about it.

Well, the problem is the math involved in the inverse kinematics. All known kinematics for serial manipulators and many others suffer from singularities where the results become infinite for certain values (See also "gimbal lock"). This effectively means that it is necessary to be able to use coordinated moves (using the non-trivial kinematics of say the KDL library) AND Joint moves (using trivial kinematics) that directly use joint angles in the "gcode". In LCNC I can use dewey garretts "switchkins"-branch to do just that: switch between "trivkins" and "genserkins" inside a gcode programm.
For this reason I had hoped it would be possible to wrap the access to the KDL kinematic library inside a modified LCNC-kinematics file. So instead of doing the forward and inverse kinematic calculations inside the C code of the kinematics file it would be piped through another file using the KDL library.
As I'm not a programmer I have no idea if this is totally ridiculous but it seems the easiest approach to me.

@Aciera ... I'm not a programmer if not an amateur either ... but kinematics, even if they can reduce singularities with if / than cycles, cannot decide the speeds in which the algorithm transforms 3d positions into angles and vice versa and above all they cannot decide whether and how quickly 7 angles transform the position of the x axis and vice versa. Here the graphic part and the functions fall into a ballet that brings several problems to QT I believe. This is why for the graphic part on QT it is preferable to use QML ..... So yes I agree with the possible problem of kinematic calculations, but also possible rendering problems and in addition to this the age-old problem of LIMIT2 to be included in the kinematics complex otherwise Lcnc makes you splash the values ​​in an unreasonable way even if well calculated ( try to love your mitsubishi near the edge of the work area and you will see how Lcnc reacts ... this to explain the concept, but I know that some they solved but I don't know how because I didn't go into the problem .... it would be nice if they shared at least the solution theory and not just the video on youtube ).

regards
bkt

Certainly doesn't look like there is going to be an easy solution for all of this in the near future. I've kind of shelved the whole QT KDL thing for the moment as I can't get my head around the whole setup and I'm just not enough of a programmer to figure out all the compiler errors.

I had some experiance with old KUKA robots in the past. They also have singularity points. In that critical points it doesn't work properly if move point-to-point but only in fast move and "jump" singulatity point.
But if it approach to singularity point in poin-to-point move it changes it axis angles (also doesn't keep tool position precisely) and keep moving after rebuilding it.

Hi everybody.
I'm ashamed of Grotius leading a topic on the forum forum.linuxcnc.org/27-driver-boards/4031...on-ethercat?start=40
And he gave me a link to his project and I try to build them.
I settled on an error. But "iso live-image-amd64.hybrid.iso, 3.275Gb" is broken.
Can you give me this iso or give advise to fix it?

TheRoslyak wrote:

I did it. It's work
The questions are as follows:
1 Now It works in linear move. Can I simulate circular movements or G64 in hal files?
2 I find 16 joint (0-15pcs). In theory, I could manage them. But RSH is not suitable for this, because there are no free letters:)
How can I use them independently? May be New HAL or any else?
3 In general, it would be nice. Make a new application based on Linuxcnc source. Why did you give up the idea of ​​"STUXNET_Cascade". I still don't understand this new app or plugin for Linuxcnc.

PS I have a lot of ideas and solutions, but I will discuss. I'm waiting for a dialogue

Ну так ты же это сделал! Сделай еще раз? Какие проблемы? Фонды у тебя неограничены

Как бы да. Но фишка в том что с его прогой (как я понял) один робот не влияет на другой. А через хал компоненты и linuxcnc - это работает в рамках одного робота!


PS То что я сделал Это скорее помогло познать как писать собственные хал компоненты. Если не трудно можешь скинуть свои контакты или ссылку где можно обсудить нанную тему. Что бы здесь не флудить своим Русским речитативом)