Advanced Search

I've decided to release a 'Starter Edition' for Arduino Uno to let everyone test the driver's performance. Details and download link are available in the technical thread here:
forum.linuxcnc.org/27-driver-boards/5823...cal-feedback-request

Quick update: I’ve just finished the 'io_decoder _eval' firmware for Arduino Uno.
I'm currently drafting a quick-start guide and a wiring diagram to make the testing process as smooth as possible for everyone.
I expect to release the package (firmware + documentation) this weekend.

Stay tuned!

phino wrote:

To clarify, the suggestion was not to validate use with Aerotech controllers. The thought was just that it should be simple enough to configure the analog input/output to use the sensor with the existing system available. That would allow testing the sensor's functionality under different conditions, if that would be of use to you.

It seems that I may not have fully understood what you expect and how you would like to test it.

it is compatible with mesa default setup, but you need add the jerk parameters in the ini file, look at the axis_mm_scurve.ini file


I wanted some feedback from the community about s-curve, there a few considerations to make, not just jerk spikes

I think there are some choices to make, when trying to respect jerk limits, we can:

1 - Slow down at curvature changes: reduce Vel so the centripetal acceleration change is manageable. (this defeats high-speed machining)

2 - Modify the geometry: insert transition curves (clothoids, Bezier, splines) that have gradually changing curvature. This eliminates the discontinuity but changes the path. (when G64 Px is too small you will see jerk spikes)

3 - Accept the spike: the programmed path has a curvature discontinuity, so the motion will too.

There is no fourth option. You cannot maintain velocity, follow the exact programmed path, AND have smooth jerk. we need pick two.

ok let's try this:
Since your handler isn't modified, replace it with the one I supplied. It's ok to keep your modified ui file in the config folder.
Of course you still need the INI changes.

If you do want to modify the original handler for other reasons, that can be done, you just need to add most of the code in the handler I supplied.

Just to be complete Qtvcp will use the default handler and ui files unless it find either or both in your config folder.
In the case of the handler file, it's possible to make a special handler file that loads the original and then extend it.
This is nice as if the handler gets updated in linuxcnc, you will get those changes and then the local changes are added on top.
 

Does it compatible with mesa based setup ??

Neulich war ja die Rede von einem Parameterprogram für Vieleck, mit Eckverrundung. Meine Inspiration von gestern hat tatsächlich zu einem Ergebnis geführt.Es können die Anzahl Durchläufe pro Eckprofil, oder Anzahl Ecken mit Erhöhung um 1 bis Max Anzahl Ecken eingstellt werden, und natürlich der Eckradius und Umkreis.Nach der Sternchenlinie würde ich nicht zwingend etwas ändern. Drehzahl brauchte es bei mir, um G1 zu simulieren.Die Aktuelle Einstellung geht von 3 bis 22 Ecken mit Eckradius 5

 

Check you hardware estop configuration

prokopcio wrote:

Hi, Unfortunately, I have no experience with Aerotech.
As I mentioned, the sensor was developed for my own needs, but I would like it to be easy to use also in open-source control systems such as LinuxCNC.
Trying to use it at this stage in closed, good working solutions does not make sense.
I appreciate your willingness to support me, but at this point it is not a good idea.

Understandable. I agree with the aim of validating the functionality of the sensor with open source controllers like LinuxCNC.

To clarify, the suggestion was not to validate use with Aerotech controllers. The thought was just that it should be simple enough to configure the analog input/output to use the sensor with the existing system available. That would allow testing the sensor's functionality under different conditions, if that would be of use to you.

Looking forward to seeing tests of this sensor by others with LinuxCNC-based laser systems.

Yep, that was it, thank you. Somehow I missed the AXES=3. Another question, my E stop button stays bright red the entire time, it still works. It just never changes from red to shaded.

It's telling you that you have not defined everything required for that function in the initial file.

kcjengr.github.io/probe_basic/machine_config.html

 

 

I just updated to the stable version of probe basic, installed using the APT stable install and running Linuxcnc 2.9.8.  During testing I have most functions working; however, I get the following error when I click on the "go to home" and the "go to zero" buttons. "Named parameter #<geomery> not defined" The error message is the same for both buttons.  Any suggestions on this error?

bcorley wrote:

A test device would be great. What information do you need to get it to me?

Are you still interested and would you have time to test the sensor?

If so, please contact me, preferably through the Proma-Elektronika contact page.

Did you build ehtercat yourself?
My two cents, don't use the official build, make one yourself with disable EoE disabled, and use good shielded cables.

Hi, Unfortunately, I have no experience with Aerotech.
As I mentioned, the sensor was developed for my own needs, but I would like it to be easy to use also in open-source control systems such as LinuxCNC.
Trying to use it at this stage in closed, good working solutions does not make sense.
I appreciate your willingness to support me, but at this point it is not a good idea.