Advanced Search

cmorley wrote:

This should be moved to the Qtvcp section..

Done.
Thank you.

I've never moved anything in a forum before, how do I do that?

This should be moved to the Qtvcp section.
Looks promising! Keep is updated! If you get stumped with the programming i can try to help.

Does joint.N.amp-fault-in actually turn the machine off?

Yes, it does.

Not near a machine so i can not confirm this, but IIRC:
Yes it does Disable the machine.
No, it does not trigger e-stop.

Does joint.N.amp-fault-in actually turn the machine off?

Yes, it does.

I don't know about the file size @scotta ?
But scotta made the beta to try and solve my CSS problem. I still have no solution. If you have the RT1052 controller. Let me know if you can get the CSS working on your build.

Hi all,

I want to share an experimental QtVCP macro I am currently working on:
LatheEasyStep.

It is embedded into the QtDragon lathe panel and aims to simplify
lathe programming by replacing manual G-code writing with a structured,
step-by-step workflow (facing, contouring, parting, threading, drilling,
keyways, etc.).

Each operation is configured in its own tab with tool, spindle, feed,
coolant and geometry parameters. The macro then generates a complete
lathe program, including comments and basic safety moves.

Important notes:
- This project is NOT finished.
- The G-code generation still needs restructuring and improvement.
- I built the first working version with the help of AI, then refined it
  manually. I am very aware that this often leads to suboptimal structure,
  which is exactly why I am asking for feedback.

What I am especially looking for:
- Suggestions for a cleaner G-code generation architecture
- Common LinuxCNC lathe pitfalls I should explicitly handle
- Ideas for improving safety, validation, and workflow
- General QtVCP / QtDragon best practices

The project is GPL licensed and available here:
github.com/peter-pan08/LatheEasyStep

Critical feedback is explicitly welcome. I am more interested in doing it
right than doing it quickly.

Thanks in advance!

 

Hi All, 
At some point the S-code could be used to command the spindle speed. The control sends an analog voltage to the LARRIOZ speed control card. The card reads a sensor that counts spindle revolutions and compares it to the commanded speed. The card can then switch relays, that in turn switch the contactors driving the motorized CVT transmission between spindle and spindle motor to increase/ decrease the spindle speed as required.
 
This never worked since I got the mill. I did at the time try to get it to work, but due to lack of knowledge and/ or documentation, I could not get working. I would think that the lithium battery in the Dallas non-volatile SRAM would be long gone, but I am not sure what would be stored in SRAM. I assume (While I know not to assume anything) that the firmware would live on the EPROM and the SRAM might hold parameters relating to the specific installation. Other than JP 1(Jumper), and P1 (Potentiometer) there is no other configuration or programming port on the LARRIOZ HABIKON1 board.
Although slow, I prefer this system, as I would not sacrifice low speed torque, as would be the case with using only a VFD for speed control.
I suppose it would be fairly easy with modern microcontrollers to get the system going again, but I would be happy to hear from others as to their experience or suggestions as to how I should proceed.
Regards
P
 

Also, how can a person do roofing, plumbing, parquet flooring, and CNC?

Multi-talented! perhaps too multi-talented!

Stop offending people, i will not warn you again!
Instead, go read through this forum, watch pictures and videos, you might get some appreciation about what our members here are capable off.

It would probably be a good idea to add MaHa's G10 solution to your startup code..

endian wrote:

Did anybody get it to run with Rods guide??

E.

I don't think it works.  The master is meant to sense if of EoE is available but 2 things collide.
1. There is a bug affecting this drive in the ethercat master
2. the Linuxcnc  driver does not support EoE

I think without the bug it should fall back to supporting non-EoE mode but its a long time since I looked at this.

Does joint.N.amp-fault-in actually turn the machine off? I'm not sure it does. I know it stops motion. My thinking is that conce you have the machine dialed in you will never get this error.

Aahh shoot! I was hoping to avoid resoldering my DIY pullup resistor board. But thank you for the explanation.

Hello, I was trying to change the bitfile in my 7c81 so that there would be only one 7i78 on port P1. Port P2 would be freed up for separate MPGs for X and Z axes. So there would be no need for 7i33 (which would probably be another complication I wouldn't go through). But in the Mesa firmware there is no 7i78x2 configuration, nor 7i78 for Xilinx ISE (*.xise). Is it possible to download this configuration somewhere else?

Good morning, I have looked at the code now. Clear out the whole loop() function and insert just this line

That should do it. You never called ecat_slv() in cyclous mode.
The danger of using someone else's code.
It meant it never used spi to query lan9252 for changes and updates to register etc etc.

There were a lot of diagnozing and trouble-shooting with the I2C so I wanted an easy way
to run the board as a normal aurduino without the ethercat things. It was required to define ECAT
during compile for it to be an ecat device. Now that is gone, so remove all of that.