Advanced Search

There are 3 limit switches for xy and z. From what I can tell there is a hard e stop switch (and this has dogs on both ends of the travel), there is a switch at the bottom that I'm pretty sure only tells the control to slow down and approach. Then there is the actual limit switch in the middle. The confusing thing is that when the middle switch is triggered the axis keeps moving until it gets to a few millimeters before the estop switch. So my assumption is the control see the middle switch then moves at the same rate to a soft limit and calls that machine zero. Why do you guys think they do that? Why not have the dog in the right spot to just stop?
This photo shows the x axis homed. 
 

got it

I popped the cover off the spindle belt.
 

Looks like its in great condition (from what I can see). 
 

 

The tool carousel rotates around the spindle when the spindle is raised to a second home switch above the normal travel. This is just like more modern brother machines.
It uses a "dumb" induction motor to move the carousel to each pot location. There are hall switches on the motor shaft that read timing dogs. Those switches turn on or off the relay and brake - sending 3 phase wall power, then removing the power, then shorting the motor wires. This works in conjunction with a geneva gearbox.
 
The gearbox output has a dead zone of about 30 degrees or so that doesnt rotate and isnt back driveable. This gives enough precision for the carousel to move to its pot location and stay put until controlled to move again. Its neat to see how back in 1990 what design decisions they went with. Spend the money on expensive gearboxes but cheaper motor/control. Unfortunately the carousel moves through its travel very cluncky starting and stopping with great energy spent at each tool pot. Much to my delight it was very easy to replace the geneva gearbox/induction motor with a 60mm servo and planetary gearbox. Now I can simply use g code to control an axis with smooth accelerations and drive to the pot I need rather than stop and start at each one at full current!

I drew up a bracket and 3d printed it to mount the servo. 
 

Then I drew up and printed a shaft size adapter to go from the 14mm my servo has to the 22mm the carousel needs. 
 

The prints are just pla but 100% infill and they will work great until the retrofit is done and I can machine brackets in metal.
 

Pretty damn satisfying solution. 
 
You can see how the tools pull stud clears with room to spare!

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?