Advanced Search

Is this open loop in the sense that you do not actually use the encoder
or its index for position feedback?

Here is 5I25T firmware for the Haase parallel interface.
(just a minor bit different than Benezan)

 

Note that a stepgen (stepgen4)  is used to drive the chargepump pin
(pncconf knows how to set this up)

Hi tuxcnc,Thank you for your feedback and suggestions! You have actually touched on two of the next major features we are planning: physical tools and tool measurement.I think it would be useful to explain the underlying concept of this simulator, because it is slightly different from a traditional G-code simulator.Our goal is to simulate a real CNC machine, including its capabilities, limitations, and potential mistakes.A real CNC machine does not interpret G-code itself. LinuxCNC is responsible for interpreting G-code, planning trajectories, applying tool offsets, and controlling the hardware. The machine simply responds to the commands it receives.We want our simulator to behave in exactly the same way.The virtual machine will have its own physical state: axis positions, spindle, installed tool, tool geometry, workpiece, sensors, and eventually machine geometry and collisions.An important design principle is that the physical state of the simulated machine must remain independent of what LinuxCNC believes that state to be.For example:

• If LinuxCNC requests tool T5 but the operator installs the wrong tool, the simulator should use the geometry of the tool that was actually installed.
• If the physical tool length differs from the value in LinuxCNC's tool table, that difference should affect the machining result.
• A virtual toolsetter should be able to detect the actual tool length, just like a real toolsetter.
• Incorrect offsets, incorrect tools, or incorrect workpiece positioning should be capable of producing incorrect machining results or collisions.

This behavior is intentional. We don't want the simulator to automatically correct mistakes that would also happen on a real machine.For the same reason, I would prefer not to intercept or reinterpret M6 using a custom REMAP. We should instead investigate how to model the machine-side tool-changing process through the normal LinuxCNC interfaces, without interfering with an existing tool-change implementation.Of course, the simulator should also support automatic tool changers in the future. The important distinction is that a requested tool change and the tool physically installed in the spindle are not necessarily the same thing.We have also completed the first virtual spindle implementation. LinuxCNC can now control it through the normal spindle commands, with encoder feedback returned through the Stepper-Ninja interface.Our next development steps are the physical tool model, tool changes, and tool measurement.Your feedback is very valuable because it helps us identify what is needed to make the simulator useful for real LinuxCNC configurations.Thanks again for testing the project!

Are you in Germany or thereabouts?

Hi everyone,  I wanted to share my progress on developing an EtherCAT slave for the Colorlight 5A-75E board integrated with LiteXCNC, and hopefully get some advice from the community.The basic skeleton of the firmware is ready. The board is alive and successfully responding to the master's initial requests—the physical layer and core logic are up and running. Right now, I am focusing on debugging the SII  EEPROM emulation. As soon as board gets to PREOP/OP state, I will share further updates. 

I would make this a private message if I could but I couldn't find how to.

I previously answered but my account was banned, possibly because I mentioned a non-linuxcnc project I'm the creator of, so after being unbanned (thanks), I won't mention it again.

So I'll keep it brief, I'll say is I'm interested in helping, and my email is This email address is being protected from spambots. You need JavaScript enabled to view it.

Cheers.

Hello.
I am using a Mesa 5i25/7i76/7i85s setup with LinuxCNC 2.9.4 on a milling machine.
I am using an open-loop control configuration. The axes are equipped with Chinese Sino optical linear scales, which I want to use for precise homing. AI helped me write the HAL and INI files for this setup. Before I added the BACKLASH parameter to the INI file, the system performed homing correctly and accurately using the scales' index mark; however, after adding BACKLASH, accuracy and repeatability were lost—sometimes it was accurate, other times not. I have attached the HAL and INI files. Could you please advise on how to fix this issue?
I read that this can be resolved using firmware that supports step/direction indexing, but I don't know where to download it.
Thank you.

Sorry that I answer to this leech. Iḿ currently try to connect a Haase 2500 pro via Mesa 5i25T directly with a parallel cable. Can somebody provide me the matching firmware and what I have to change? Iḿ a little bit lost, sorry....

Thank you! Roland

Hi, I have a Gildemeister GDM 42 retrofitted with LinuxCNC, featuring two turrets and a sub-spindle. I’m looking forward to a solution like yours and would be happy to test it out.

I was gone for three years or so, cause I was moving house and shop.
I really fired um my lathe yesterday for the first time and updated to late latest version.
Great job guys and a big thank you to all who ware woking on the project, remembering how everything started this was smooth!
Just some things from my side to consider with the changes in the INI.
But it seems to run now and the conventional cycles are great now.
There are two thing I am missing.
One is, I would love to have a Hal pin for the jog increments to use fron the GUI. I have a user tab now for that, but I could use the space for some other stuff.

And a safety zone before the spindle. to not crash into the chuck, but to be able to also machine without one.
Kind of a tool table but for lathe chucks. then one also could set a limit to the RPM depending on the chuck.
At the moment I need to edit my ini for that.
But maybe there is already a solution for that. besides ignore limits.
I guess I'll give this lathe chuck extension a try, to get back in the LinuxCNC handling. I'll open a new topic for that.

This is a great project that may beat all others in the future because it supports all LinuxCNC g-codes, including those that will be added in the future. I'm not kidding, the simulator will show all the movements that will be sent to the virtual controller, no matter how they are generated.

Unfortunately, the project also has many drawbacks, which is not surprising at this stage of development, but makes its use in practice very difficult.
What I miss most at the moment is tool changing.
Of course, LinuxCNC will replace the tool, but the simulator will use only one, configured in its own ini file...
Honestly, I don't really have an idea how to solve this problem.
I thought about REMAP M6 in an ini file that could run any program, so also one that would inform the simulator about a tool change. But what will happen when the user wants to use his own REMAP M6 and see its operation in the simulator?
By the way, simulating tool measurement would also be useful...

I was able to run the GCode above without issue, so I dont think its your GCode

tuxcnc wrote:

I deleted all the G54s. Where will you put the G54 now (important information) and why will it be better?

On top like in my example image.
This also has the advantage that on touch off the task bar doesn't hide the X value like it currently does (in fullscreen mode).



I also talked with Norbert that we might don't display the coordinate system at all in the DRO, because it is already displayed in the G-Codes section.

Ah, got it, thanks. The supabase.co one is also mine. Supabase is a hosted Postgres database (open source, basically a self-hostable Firebase alternative), and it's the backend of the site: license keys and trial activations, the small forum on the site, and site settings like prices, download links and the support e-mail.

The footer pulls the support e-mail from it, that's why you see it on every page. It's just plain database reads, no tracking or ads.

HansU wrote:

Because the window is wide and low.
Removing G54 from all but one line will not give us any more space to display anything.
However, moving G54 to another line requires adding a new line, which means there will be less height for the position and more width, which we already have in excess of...
I'll say it again.
A CNC machine is not a toy, it may damage something or injure the operator, so the most important information and buttons must be large, legible and easy to find and use.
Whether it will be pretty or ugly is secondary.

I deleted all the G54s. Where will you put the G54 now (important information) and why will it be better?