Advanced Search

Hi all, i have a problem.
If i open tooltable to edit tool and  power supply goes out tooltable is crashed,
If i open tooltable to edit and go to shut down my pc, tooltable is crash.
How to fix it problem?
The power in my workshop often suddenly goes out because the electricians are repairing the old network.
 

So, I've now tested it in a VM. 

If I leave the query in the function

if((position > stop1)&&;(position < stop2))
halt=1;
else
halt = 0;
I cannot activate the machine!
If I reverse the query, I can reference the machine and also move the axis to the position support.stop1 From this point on, the axis can no longer be moved.So far, so good! 

What I still don't understand:
- Where or with which pin is the reed sensor of the cylinder connected
  The reed sensor that tells me that the cylinder is retracted! 

Of course, this is now a simulation and on the real machine it is an input on the Mesa card, but there must be a pin to compare whether the spport.halt and reed sensor of the cylinder are the same or not? 

The motion.enable should only trigger when the two signals are different. 

So the axis is between the positions stop1 and stop2:
- If halt.motion is true and the cylinder's reed sensor is also true, the axis can continue to move- If the two signals are different,
 the axis must stop, which is what it is currently doing ...

I've got most of the gladevcp buttons working on my machine; i.e. I can toggle may laser marker, I can move the table so that the quill moves to the desired X/Y coordinates, and I can set the program zero for the current coordinate system.

However, I'm experiencing a SNAFU. When the laser is on, the machine will not jog. Further, I have to turn the laser off then click some other widget before the machine will jog again.  What might be the cause and the solution?  My implementation requires that I can jog my table until the crosshairs are at the desired X/Y program zero.

These are the HAL commands to toggle the laser:

# *** Crosshair laser Toggle and LED ***
net machine-is-on => gladevcp.crosshair-ctl-active
net crosshair-toggle-out <= gladevcp.crosshair-toggle
net crosshair-toggle-out => gladevcp.crosshair-led

The LED is set to flash when the laser is active as a prompt to turn the laser off after use.

Kind regards;
 

What do you mean with firmware? The bit-file?

If you mean my IO Connections for the 6i25 they are shown in my first post in the last source code section.
I made my own bit file matching the in and outputs of the mach3 bob.
The 5i25_5ABOBx2.bit is matching my china bob?

Can I remove the "17 7 IOPort PWM 0 Dir (Out)" in the bit file and make a nomal I/O Port out of it or must these PWMs come in pairs of PWM and PWM/DIR?.
If not, can I change a component so that the relay clicks with CW and not with CCW?

 

What fIrmware are you using? 

5i25_5ABOBx2.bit should have the correct pinout and GPIO 7 is just GPIO on that firmware

 

Thank you all. I will study more and receive help to bring this knowledge to a commercial level. I'm happy to be able to do something.

So, I've got this great idea on checking bit Z-height before running: forum.linuxcnc.org/38-general-linuxcnc-q...hecking-on-top-datum

This hinges on there being a highly reliable way to calc the lowest Z the G-code will go to- one that there's no way around like loading a file in an unusual way, or any method that changes the user offsets that either evaded  recalculation or recalculates wrong.

It seems the best way to do this would be to modify AXIS so whenever it analyzes a g-code file, it saves the lowest Z found in a special .nc file.  Once the rangefinder sees that someone has changed or might have changed the bit, it requires this check of a physical tool touch-off on a fixed sensor.

My current thought is that it won't try to second guess you and set your Z offset to what it thinks you want.  You'd still be in control of that.  Regardless of whether you zeroed the machine on the bed or top of the wood (which you'd want to do for V-carving), it's just going to check how deep the loaded job would go and if it's going to cut more than 0.5mm into the spoilboard, it will not allow running until it's addressed and clears a repeat of the bit check and/or loading a file that doesn't go as deep.

To do this, I figure when AXIS triggers a reevaluation on the Preview (file loading, or the user changes the user offsets, it rewrites that .nc file.  The nc file isn't anything the user interacts with directly.  The system's bit check routine just calls this external ,nc and AXIS would update that every time you load a file so it should be reliable, right? 

Hmm, what's my question?
1.  Am I correct in thinking that the evaluation it does while loading a file is definitive, except perhaps for manually written G-code subroutines/conditionals it can't display in the 3D workbox area? 
2.  And it's definitive in that there's no way it could get out of sync?  That is, there's nothing else that can change the toolpath that doesn't come through that load-and-evaluate code in AXIS?  I see the "Edit G-code" function has to do another load-and-evaluate to change the toolpath, so there's no fooling it that way. 
3.  I know it's Python and thus the source is right there, but if anyone wants to point me to the "right spot", that could be a huge timesaver.

Thanks a lot for reaching out!

Yes, in the current fork, it lives under src/emc/sterp as a plug-in interpreter.
In fact, I modeled it after studying how canterp works.

I understand that it might not gain much traction.

I'd love to maintain and extend the project as long as life permits me! Currently, I’m just an undergraduate, so I can’t promise a fixed 20-year roadmap just yet, but I've built sterp/gcode++ with maintainability in mind.
I might also extend it in the near future and add more preliminary unit tests.

Right now gcode++ extends g-code by introducing for loops, while/do-while loops, as well as imports (currently working on test cases for the same for the latest LinuxCNC release).

The inclusion of these control structures and import statements could greatly improve readability and code reusability.

It also ships with an in-house REPL for dry-running programs that can be used outside of LinuxCNC and has richer logging - I intend to add a simple debugger to it possibly in the future.

I know quite a lot about EtherCAT from reading here, but no experience, so i refrain from replying completely.
Tank you, Hakan.

Yes, I just copy/pasted the G code sample into a file.

It worked with master and 2.9.4 (I can't easily try 2.8 because of the Python 2-3 change)

I don't think the OS matters but this is Mint 20.2 with a recent kernel (6.15)
 

Did you run it as G-code? Which version LinuxCNC and OS are you using?

Service Manual for the TNC113:
product.heidenhain.de/JPBC/image/FILEBAS...C/599239-00-a-02.pdf

As far as I'm aware the glassscales directly plug into the TNC113. I rather doubt that you are going to find any EXE units in there.

you can reuse the 'iocontrol.0.coolant-mist' hal-pin and change the name in the Axis-GUI to 'Clamp'

Is it this one?
www.instagram.com/furniturenmarkt/p/CKTauBwrZ-F
Which claims that it might be the only one?

The circuit board is odd, in that it seems to have only one connection.

Do you have any pictures of the inside of the control cabinet? I would not be surprised to find that you already own some EXE units, in that cabinet.