Advanced Search

do you have the plot turned on for machine bounds in the ui? sidebar tab "PLOT"

for the dro display, you can use the user custom dro template and setup however you desire, just remove the rows for a and c and leave xyzb

for the wrapped rotary, this will be something coming down the line, we are currently working on multi axis plotting and simulation so if you have a model of your machine and would like to be a tester for the currently existing test branch you can give it a try if you like, the feedback would be good for us to have someone outputting multiaxis gcode for testing.

Hi Axemas
Thank you for your hard work. As you suggested, I’ll send a request via GitHub. I’m having trouble with the lathe tab—can I count on a reply and help? Thanks, Z

Good day everyone,
My name is Radko. I got a secondhand MAHO MH 800 C too and having some difficulties with the mill.
I am need of the electrical schematic diagram of this machine.
If anyone has a soft-copy (pdf, image file) of the schematics then please send me.
If there is a link where to get the scheme
I would be very grateful if you could.
Best regards,
Radko

Thanks; am really looking for someone I can pay to configure this system, then help with programing of the router to make a number of parts.

In Zeile N55 fährt das eine file auf X11.57 und das andere auf X-1.444, die Differenz zwischen den beiden Positionen ist viel mehr als der Radiusunterschied zwischen D3.175 und D2. Da stimm evtl was in deinem CAM oder mit den Werkzeug Durchmessern nicht.

Gruse
Max

Hi,

Setting up Probe Basic 0.6.6 on a 4-axis gantry machine (MPCNC with a fixed rotary B axis mounted at the end of the Y travel).

Configuration:
- LinuxCNC 2.9.8
- Mesa 7I76E (Ethernet)
- trivkins coordinates=XXYYZB, 6 joints
- B axis is a rotary chuck, fixed position at Y=700mm

What works:
DRO displays all 4 axes correctly using DRO_DISPLAY = XYZAB (A axis is unused but present — there is no XYZB option available).

What does not work:
The backplot renders the toolpath as 3-axis only — B axis rotation is not applied when building the path. For wrapped rotary applications (tube machining) the toolpath preview is not meaningful.

Also, machine bounds are not displayed in the 4-axis config, while they display correctly in the 3-axis config on the same machine.

Are there any plans to support wrapped rotary backplot rendering in Probe Basic / qtpyvcp?

3 axis configuration - mpcnc_probebasic.ini
4 axis configuration - probebasic_4b.ini

Pretty cool machine for somebody who had never seen one. Good for the OP to see there are other solutions.
I was envisaging much more gradual arcs. Maybe that was because I used to get 2mm rubber sheet cut with a tangential knife machine including 6mm dia holes.

When I started this, I wanted the arc radius and Andy asked me to add the tangential heading as by the time I had the radius, the heading was trivial. (so we thought anyway). It will be quite handy.

Some Yaskawa servo drivers support LRW. Check syslog for this message to know if it does

Das klingt gut. Ich melde mich, sobald ich das ausprobieren könnte. Danke.

Yes. VFR input works well. It's output for actual spindle speed

PCW wrote:

I guess my question now would be: Why are there relatively huge steps in the commanded position?
 

That's exactly the issue I can't get rid of. This is just with G0Cxx commands. I'm suspecting if I zoomed in the second plot enough it would look the same just at higher frequency. For example when homing it acts fine but that's probably because the commanded position is instantly much different and the PID loop takes care of reaching it. But here the commanded position supposed to trail ahead by some degree to let the PID do it's thing I suppose and it just doesn't seem to work with the joint either reaching the position and output going to 0 and then falling behind and shooting up, rinse and repeat... If I lower the P ratio to where it trails just behind, the commanded position slows down aswell eventually leading to coarse steps like before.

I finally checked your drive manual.  Your drive can handle 4mhz pulse input when using differential signals.

If your drive is set to the default input of 10,000ppr (parameter P0.22), and you want ~4100rpm (motor) for 6000rpm (spindle), that means your maximum pulse frequency will be ~680khz.

Tuning or inertia issues aside, it also results in a fairly coarse positioning resolution of 19 pulses per degree.

You could increase the drive positioning resolution by a factor of 4 without running in to the drive's (or Mesa's) input frequency limit. 

I'm aware that the motor is not exactly right for this, however it was already on there before me. It's the same one from the manual with 1500rpm rated speed, making for a pretty slow spindle. The 4MHz value is what I had in mind when figuring out the pulse widths and so on, I admit though I forgot about the motor rating, but for now in spindle mode I only had it in the hundreds range and in axis mode it's even slower. I will try increasing the resolution and see, thanks.

why not just align the C axis with the last segment of the trajectory? with trajectory blending on that worked okish for me on a leather cutting machine.

github.com/yur7aev/linuxcnc/blob/nyx2.8/...ponents/tangent.comp

dear sir , i hope i can explain my idea in accurately , and hope it is usefull, what if we index the code data vector sent from the interpreter to the motion controler , like a sequence segment to force the motion controller to attach and trigger the heeding calculations to the segment without override , sure ther might be some data or technic in the strcure would be helpfull without adding a new data field

I have not been able to review this further today but
In the interpreter I have added a couple of procedures here that calculate the headings
github.com/rodw-au/linuxcnc/blob/state-t...erp_convert.cc#L7080

tag_straight has a debugging print line that is correct. There is a simple gcode file here that draws a square
github.com/rodw-au/linuxcnc/blob/state-t.../nc_files/testg2.ngc
and the output in the print statement is perfect.
But the values are altered before it gets to the pins so I wanted to repeat the debugs with these files.

But look at that, I am not calling 
write_canon_state_tag(block,&_setup);
in tag_straight. Hopefully that is what's missing. I've hacked into this procedure so much, I had a clean up that went too far...

the block is written to state tags in
github.com/rodw-au/linuxcnc/blob/state-t...4ngc/interp_write.cc
both the block and the tags

the heading for the arc is calculated in motion at
github.com/rodw-au/linuxcnc/blob/state-t...tion/control.c#L2230
We need to do that because the interpreter tags are static for the life of the segment but on an arc, we need to calculate the heading at the point on the circle at every call of the servo-thread. It seems to be working but I have not validated the data.


Good luck!
 

mclien wrote:

ballscrews ar primary because the original threads in brass nuts have quite some deadway.

Just so you know, LinuxCNC has backlash compensation parameters. That said, I'm not real sure milling dies would go well with backlash. I used to have a diy CNC router with cheap ACME screws, running LinuxCNC + parport + microsteppers. I did more drilling than routering with it, drilling the thru-holes in home-brew PCBs. On that machine, backlash compensation was the ticket.