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

Hi Udo,

I think your way of doing it is ok. It is in fact that each pin must be connected to another pin to create a connection
between different kernel modules. In practical way, this can end up in a lot of connection's.

I agree with Andy and Rod that for simple components halcompile is ok.
For the readers i have a few comments.

Halcompile into C gives c-code, this is not usefull code if you compare it to a (future-component) file like stepgen.c

In my own learning curve, i stayed to long using halcompile (limited python script).
At that time i did not have the knowledge how to code a component in c
and how to compile it with gcc. Once that was figured out, i realized we have full control.
And you learn much more about c. Then you can include headers, call c++ functions from c etc.

In my view this is Linuxcnc's hidden secret weapon!
Haha. Sure not. It's a smoke curtain.








 

Hi ( when are you sleeping )

As I mention earlier I just want the LCNC as the motion controller. (I like your s-curve.)
For that I need the ins and outs of it. Now I get those from a single shm-module. Just like an extra wiring terminal.
I also get some status info using nml_status channel. Its just a pain to get all the pins and signals and params manually.
So if you know an easier way that would be great. 

// I wrote a simple component recently for a user to activate a pneumatic ram when his Z axis was moving up to help take the load//
If you have the signals in the plc - that's 3 lines of code. And you just need one module for all your ins and outs.

Now, if you want to improve or temper with HAL or the cnc-kernel itself, then you sure have to be some kind of a coding guru. !
But that is absolutely not my aim.

Now - I connect a new slave to the ethercat and all the ins and outs are there.
If you need more pins, takes as long as you need to type the names.
Need a button or signal in the gui - same thing .... not really programming ... and so on.

The only real work I see in front of me is to get those pins and sigs and params from the HAL. Pice of cake. .-)





 

Hi
different question.

Few days ago there is a new/updated motion-logger.
github.com/LinuxCNC/linuxcnc/tree/master/src/emc/motion-logger
How to compile and use / start from a terminal. Can someone adjust the make file. ?

Hi Udo,

How to compile and use / start from a terminal. Can someone adjust the make file. ?
I think easyest way is to compile the whole git clone at once. Making a stand alone compile script for this is possible,
but takes a few hours to investegate and test.
For starting goto the lcnc ~/bin folder and i think this is the executable : ./motion-logger

@Grotius: How many segments of a live-toolpath can you build before the graphics slowing down to much. 
I tested 1.2 milion lines ok. It could be more. I tested it with a huge 3d printer file from our Italian friend.
Following the github comments of the links before, the implementation should give the best performance.
I think i mentioned it before, i would like to see this implementation in combination with a algo that purges little segments
into bigger segments if possible. For example when lines are colinear.



Its just a pain to get all the pins and signals and params manually.
So if you know an easier way that would be great. 
Halview has a script that uses excisting halfunctions to read all pins and parameters, etc.
This script loops every 100ms trough hal and display's everything. I suggest this is what you need?
It is gone, but it's not much work to write such a implementation again.
But when you got this info automated.. You end up with the same problem. You have to make a connection
for every pin or parameter. Are you able to automate this step?

 

HAL Pins Qt TableView.

Now here the HAL-Pins-Viewer in life action.

Grotius: You have to make a connection
for every pin or parameter. Are you able to automate this step?

Yes. Can be done using the halcmd net command.

 
Also now loading the last selections from the previous watch-list after a restart.
Did I mention it before: I love this shi.....!


 

hi tommylight
if that is a question then the answer is "YES"

@Grotius
about that path-view:
Just so I'm clear about it; You are creating the path-segments from the g-code file.Correct ?
If so, then your approach saves a lot of segments. Dramatically. Is that what your ripper is doing ?
At the time of loading the file. ?
I'm getting my path-points by polling the actual TCP. So it's always a straight line between the points.

 

Hi Udo,

You are creating the path-segments from the g-code file.Correct ?
For the gcode preview it's creating a single line for a G0,G1. And so on. So no tiny segments.

For path interpolating, this is for each line, arc, etc.  0->t->1. Where t is time. And 1 is the max value of a normalized vector.
For example x=10.123 normalized = 1;

Is that what your ripper is doing ?
The ripper is only going to parse full size primitives. For every line of gcode, one primitive is created.

So it's always a straight line between the points.
For toolpath live preview, when line's are in the same direction, coincident, they can be merged into one bigger line to
avoid a huge std::vector size.