hal-core

Extra info:
code example

rukcig problem including video

 

Figured out the problem, had to install the qtcreator deb from your github since it was looking for the library in the /opt/qtcreator directory


Hi Grotius,

Have you ever seen this error? I started getting it after I installed Qt Designer (5.15) and I am not sure what I need to do to correct it

 

 

Hi Dave,

The quickest way to solve this, is to recomplie the qt part of trajectory component with your qt version.
This type of errors can be caused by a qt library change. Or it can not find the qt libraries.
You can add a : ldconfig ./ path to qt library in the trajectory startup script.

Hey grotius, a few questions. the s curve hal component for syncdof, would you use that within linuxcnc to achieve s curve acceleration smooth accel/decel but while maintaining the linuxcnc path planning?

also, what does it mean, "30 days trial mode", im afraid to ask...  

Hi Cakeslob,

If you use it without any lineair backend you can achieve it in some senarios. But don't expect it will do a nice job with lcnc
at the moment.

Lcnc really needs the full scurve path planner integrated.
To achieve the As=2*Am wich means, Maximum scurve acceleration = 2* Lineair acceleration.
The motion planner has to calculate the path with this formula's.

The 30 days slogan is just a joke inside that component.


 

Hi Grotius,
I have been trying out the syncrodofs module and I really like it, I just need to make a module to add its output to an offset so I can have a starting position to feed in to the kinematics module.
But thinking about it, should I use 3 of the sdofs and feed that in to the XYZ of the kinematics?
Or would I take the 6 output from the kinematics and feed that in to 6 sdofs to keep the motion in sync?
Could there be a problem with the max velocities if you sync the XYZ movement and then feed that to the kinematic, since one of the 6 axis might have to move faster than the max velocity to keep up the sync?

Hi Dave,

If you add a few lines of code inside the synchrodofs halmodule.c pin setup function.
You can add a few hal pins there to create an offset.

and then at last do a recompile with the /opt/hal-core/src/hal/components/synchrodofs/hal/./runtest.

/opt/hal-core/src/hal/components/test/test.c exactly shows how to add hal pins and set a value to a pin like the enable pin is doing
over there.

I think kinematics are 1 to 1 connected to lcnc's trajectory tcp output at servo thread speed.
Then the kinematics output can go to the dofs.so or synchrodofs.so modules, depending on what you want.

Could there be a problem with the max velocities if you sync the XYZ movement and then feed that to the kinematic, since one of the 6 axis might have to move faster than the max velocity to keep up the sync?

In general for ruckig, i think it's synchronised to respect the slowest dofs. So yes it could bring you into a problem.
For simple xyz tcp path following, synchronization has in my
opinion not really benefits, it can have even more downsides, like huge memory loads.

Or would I take the 6 output from the kinematics and feed that in to 6 sdofs to keep the motion in sync?

I personally would take the dofs component. /opt/hal-core/src/hal/components/dofs/hal
This is a runtime fast solution. And yes. After the kinematics using a Dofs make's sence.

Some background info. There are options to set some dofs values in the cpp_interface files.
This are all the enums explained :

•         //! enum: position, velocity
•         in.control_interface=ruckig::ControlInterface::Position;
•         //! Phase, ///< Phase synchronize the DoFs when possible, else fallback to "Time" strategy
•         //! Time, ///< Always synchronize the DoFs to reach the target at the same time (Default)
•         //! TimeIfNecessary, ///< Synchronize only when necessary (e.g. for non-zero target velocity or acceleration)
•         //! None, ///< Calculate every DoF independently
•         in.synchronization=ruckig::Synchronization::None;
•         //! Continuous, ///< Every trajectory duration is allowed (Default)
•         //! Discrete, ///< The trajectory duration must be a multiple of the control cycle
•         in.duration_discretization=ruckig::DurationDiscretization::Continuous;

 

Hi,

Just did a archive update for hal-core.

The update is showing the matrix component doing a gcode motion.
The motion is done by a new trajectory planner i am coding at the moment.
I had difficult times to code this. Mainly trough the user interupts like velocity changes during runtime in combination
with a new scurve library.

1. The trajectory planner has the s-curve implementation.
2. It accepts acceleration changes during runtime.
3. It accepts velocity changes during runtime.
4. It can do a forward motion trajectory.
5. It can do a reversed motion trajectory.

It is not ready, but it is usable. Have to code several things, and clean up a little bit.

A short video




 

 

Hi,

A tiny update.

I am soon at the point it is usable software for motion planning.
Some effort is done to get the source code nice and clean.

It's still possible to load multiple machines at the same time, including separate gcode and motion at the same time.
I coded every machine as a stand alone widget. Then the program load's an instance of the widget, like "machine 1=new widget"

The gcode can be rotated and placed on the machine bed in 3d.
The machine will follow the 3d gcode positions relative.
The machine can be a robot, a gantry or a exotic kinematic model.
The entire program is just one hal-component, in this case called "matrix.so"

I have to code some parts yet. But the diffuculties are behind us now !




So far so good. And don't forget your 4'th and 5'th and 6'th booster shot.