Advanced Search

OK I've got my machine setup to use geany as the program text editor in my ini. program would upen if i hit "edit" gui button.  Tool table wouldn't open using the drop down in axis. My tool.tbl does work though, as I can open it externally and add tools and linuxcnc picks it up. Then I tried switching my ini to use gedit just to see what happens.  It appears new linuxcnc doest have gedit anymore so it didn't work. Switched back to geany, and now neither tool table or program edit works. Seems buggy. Will my pyvcp panel work or easily port to a not-terrible gui?

Hmm I'm not seeing any options in Debian to auto login. I did some googling here and there over the last few weeks and havnt found a good way yet. My 10+ year old Ubuntu linuxcnc machine seemed a lot simpler to get going. Debian seems annoying so far.

Hi Andy,
yes it is that machine, It is not the only machine, it is the only prototype of the NC version..

My information is, that over serveral years less than a total of 20 units of all versions were built and sold.
There were 3 versions available
- a manual version (can be seen on on lathes.co.uk)
- a NC version like mine with combined servo-drives and handwheels
- a CNC version with a Siemens control,unit an without handwheels (there ios one on Ebay in Germany - can be fpund under "Prätecma")

Best regards

Hartwig

Niiice !!

Do you have power connected to the orange TB1 header? The Jumper W1 connects VIN to VField but you still need to supply power to VField/VIN and GND. My 7i76eu is powered entirely by 24V going to both TB1 Pin 5 / Pin 8 for field voltage and TB3 Pin 21/ Pin 24 for logic power. My PNP sensors work flawlessly although it took me some time to figure out how to set the inputs to sinking/sourcing.

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.