Advanced Search

this might be a dumb question but why is it called pwmgen if it is an analog output? is it because of the old 7i96 (without the "S"?)

i will try this out soon and update on the results

The tool changer on this thing is relatively simple. Which makes it more attractive for the retrofit. There is no pnuematic drawbar release. Instead it has a big lever arm that rides up a ramp. This mechanically releases the tool at the right location and is controlled purely with the z axis.  
 

Okay so if true then the axis must home on start up.

3.10. VOLATILE_HOME
If this setting is true, this axis becomes unhomed whenever the machine transitions into the OFF state. This is appropriate for any axis that does not maintain position when the axis drive is off. Some stepper drives, especially microstep drives, may need this.

Wouldn’t this assist with the home routine where the axis home is stored in ABS and required no home? If false, then read the ABS, set joint homed true. Set the machine coordinate to the current ABS. Homing done. ?

Seems you could also create a bool to switch back and forth between the gantry mode and independent mode. Say you had X and U as your tandem axis set. You could then when independent move the motors and measure the square of the gantry. Once square, set the ABS for each drive, then switch back to tandem axis control in LCNC. Done?

Seems somewhat logical to me, but unsure what has to be done get that into code yet.

alex_sar wrote:

If I make this change and submit to Github to merge, will it be accepted? 

If you do not try, you will never know.

Not a developer but sounds great especially
for complex gcode or slower machines.

Probably best in a separate branch initially.
 

Hi All,

I tried to rewrite Gremlin - make new widget based on existing code and contribute it. It made with using of recent OpenGL ES API (shaders/vertex buffers/etc.). The code is not ready to show yet, but I got all parts working and it is possible to make it handling bigger g-code files and do it fast enough. Currently big files simply excluded from preview. At first look, the problem is large Python trajectory arrays that filled one-by-one and then handled in Python again with lot of iterations. I rewrote it to use number of continous memory buffers (fixed size each) and it made a big change immediately. That is not the question, I hope I can show results soon. Just want to ask if anyone have interest in this new widget?

Another big deal is number of calls between C++ code and Python code. I did not measure it yet, but gcodemodule.cc does calls like this for any point in trajectory:
When it repeated n*thousand times, it becomes a bottleneck for sure. My idea is to modify methodand add an optional parameter for this to accept C method pointers for "straight_feed", "traverse", etc. So when this parameter passed, it will call C callbacks instead of python methods and do not do all this Python variable conversion back and forth.  Something like thisI believe this may be a huge performance win and I hope it does not violate any LinuxCNC development guidelines.
My question is to project maintainers. If I make this change and submit to Github to merge, will it be accepted? 

No, the images are different.
If you wait a couple of days I can create updated ones for both versions of Raspberry

helvio wrote:

I like to use 180lpi linear encoder, my question is, linuxcnc count all four transitions on phase A and B. Because if only one count is used, we have 25.4/180=0.14mm resolution, and have to adjust DEADBAND to 0.14 finally only 0.28. In the other hand with 4 transitions counted have 0.035 and adding DEADBAND 0.07. Is for woodworking cnc. Thank
 

Yes, LinuxCNCs encoders (software or hardware)  usually default to 4X quadrature

That looks like basically what I was suggesting

The 7I96S pin name is not correct though, it should be something like:

net final-power scale.1.out hm2_7i96s.0.pwmgen.00.value

(you also need to enable the PWMgen)

In the html documentation for 2.9, specifically page:
linuxcnc.org/docs/stable/html/getting-st...dating-linuxcnc.html
I believe an update is needed.  I am not sure how to suggest an update, and wanted to ensure what I found was indeed a problem.

In the 1.1 Apt Sources Configuration, there is a Table 1, that shows the Repository information for the various Debian versions and kernel type.
It appears the Repository information for the Debian Buster - preempt, has the wrong information.
I was attempting to update from 2.8 to 2.9 and hit a snag on the step where you add the new repository to the synaptic package manager.  It kept saying it was not found/good info.  
I then stumbled across this page:  linuxcnc.org/dists/buster/ and found that for 2.9 there is not a rtpreempt folder but rather a uspace folder.  So it appears between 2.8 and 2.9 the folder for buster has changed.
I updated my repository information to replace what was in the chart, changing the "base 2.9-rtpreempt" to "2.9-uspace base" and then the synaptic package manager found the repository and I was able to update to 2.9.
 

On L615 there is a bool for volatile_home. What is the meaning of this state?

pippin88 wrote:

So really the gantry function is not needed / helpful when we have a full controller (such as LinuxCNC)

And what we need is to be able to configure 'home offset' whether homing is done fully in LinuxCNC or in a servo drive

Ys, this is all that's needed. we include homing.c in our homecomp which in turn loads homing.h
This code that sets these parameters is called from our homecomp github.com/LinuxCNC/linuxcnc/blob/master...motion/homing.c#L607
 

Thanks for the clarification. But, I was talking respect to the Delta tandem axis solution which gives LCNC control of only one drive while that drive controls the tandem drive. Not ideal at all.

I have not seen where the tandem axis control is open to ECAT. Did I miss that? I know for the standard non-lcec servo thread it is. If so, where is the documentation for that to setup the ini and hal for ECAT tandem axis(aka Gantry) control. If this is already available, then yes homing becomes much easier and can be controlled by LCNC in isolation for at least the ABS multi-turn condition.

So, let's understand this. Can LCNC with lcec provide proper tandem axis control of sync'd motion? IDK... If so, what is the best practice for the ini and hal configs?

On that thread, what is the best practice for providing a known datum(homing) that satisfies the tandem axis problem?

Option 1 - Use the drives encoder out pins to a Mesa card and let LCNC see the Z index for each motor for non-multi-turn encoder drives
Option 2 - Use a scale with Mesa to do the same thing if the drive does not support RS422 output and also uses the home to index/ref marker from the scale
Option 3 - Use the ECAT derived FB POS as the failsafe actual position and write routine in custom homing that simply uses the multi-turn recorded and stored position value to call the axis "homed" then simply move the axis or tandem axis to the zero location from that derived position

Once homing is complete, will LCNC close the loop for the tandem axis as it does in the non-lcec setup? Or is open loop good enough? I would think so given the drives are ECAT on 1ms ticks. More than ample for low error sync. That is how the big boys do it. I see no reason why it would not work here other than the slight .02ms lag over the lcec bus as compared to a standard ECAT system. iGh has the timing table in their docs. I don't see an issue unless the machine exceeds 2000IPM. Which if so, I would not use LCNC. I would buy a Siemens control. ECAT chips are mature enough now but I am still always suspicious of motion at those speeds. For good reason.

I think we are making progress here at least in terms of speaking a common language. It inspires me that soon a solution for the problems will be found. Thanks for your kind assistance. LCNC may soon be let loose from the stone age! Lol!.

Donb9261 wrote:

I am thinking the best solution for the entire LCNC and ECAT is to do the same as what Siemens/Fanuc have done and find a solution for homing that makes sense based on true ABS encoder technology. There is a net savings in cost in doing this as well as ensuring the precision required. The cost savings comes in the wiring and reliability aspect. Less wires less cost and less chance for things to break. And it maintains proper separation of concerns with a true master slave setup.

I will be looking at how to change LCNC to act more like the CNC ECAT standard vs. trying to reinvent the wheel. Currently LCNC has a single mode for positioning. Command Position Mode. Which is the same as S/D mode using a Mesa. The drive is in follow my lead more or less. This creates some questions as to whether the ECAT interface in LCNC can use the same functionality of the standard interface within the ECAT interface. Can LCNC use the ABS POS FB as the FB to close the loop on the LCNC side? Will the driver do an actual tandem control? Can LCNC custom homing work with a "home in place" "update position to current ABS POS FB, then assume homed?

 

Don't get to carried away. Linuxcnc has been homing for a long time. Many of us don't want to spend on high quality absolute encoders and that is not mandated by the  ethercat standards. In fact, the cia402 standard does not care how a joint is homed and neither does Linuxcnc.

Whilst the documentation may be sparse, the code base isn't. You need to read and understand homing.c and how homing works as discussed in the docs under homing configuration. When you read that you will see that our home comp knows the home offset and homing sequence of each joint.
so we now know that after a joint is homed, we need to move the home offset and if the home sequence is negative we need to move it in unison with the matching joint with the same negative home sequence number.

So gantries don't sound hard at all!
But said, we need to get 1 joint homing first.
I'm quite happy about what I found out tonight because we don't need to litter our home comp with additional pins!

 

If you have these two lines in your hal:
loadrt tumbler_decode names=decode.0
addf decode.0 servo-thread

And you are still getting an error then I would comment out all the hal lines that contain 'decode.0' pins to get linuxcnc started and then use the 'show halconfiguration' tool to check that the 'decode.0' component is actually loaded and what pin have been created.