Advanced Search

Hello, Str8jacket,

would you mind sharing which US based company you ordered the encoder adapters from? I am looking to retrofit a Deckel Maho DMU 50M (very similar to your 50T, but with LS486 encoders instead of LS486C). I too am currently wondering how to convert the signal to TTL properly. It's looking like the only tried and tested solution is the Heidenhain IBV 600, but they are obscenely expensive, I may as well change the entire encoders.

I also found those Aikron adapters and am wondering if they'll do the job. Are they the ones you ended up going with?

Thanks.

No, the heads were mounted on a fixed spacing in the X direction (15 inches.)

It is a complex configuration with a lot going on, including HMI integration for the onscreen buttons to enable/disable each of the heads. I posted the link for you to try to see what it takes to slave an extra joint to an axis.

I also have posted configs for some two head machines that are set up as XYZW control. These have the ability to be ran using independent Z and W commands. While they still are configured using fixed spacing between the Z and W heads, they do also have the option of programmatically slaving the W head to the Z head so the machine can run on XYZ code with the Z and W performing the same movements. This is accomplished using a few custom M-codes, some g-code subroutines and a bit of hal trickery. (I'll have to try to dig up a link to where it's posted.)

A basic system with XYZUW axis would not be that hard to set up and not need to be very complex and use the ordinary standard Trivkins kinematics. If set up where X and U are simple absolute position commanded from a single fixed origin. However if you wanted the U axis to command the spacing between the Z and W heads, That would require a custom kinematics program, but I don't think it would be a completely unique one. I believe this type of arrangement has been used for some knee mill configurations. (Not sure I've seen example configurations posted though, but there is a good chance there are some out there.)

youtube.com/shorts/b2f-urW5Wb4?si=VfSc_KL7Y7zgTUn_

I'll try and get a video of this and upload it.

www.youtube.com/shorts/b2f-urW5Wb4

So, load file - no worries.
preview opens a long way from 0,0
cuts in location
frames where preview is shown.

Could it be the post processor?? 

The project started  before qtplasmac came out and I kept the plasmac config I did with Tommy a while back. I would like to get the machine working nicely as is before any software upgrades. If moving to qtplasmac will help with optimizing stuff I can give it a try. Next step is tuning the height control (Z) movement. Right now the Z is moving up and down only when sensing the metal sheet and then when the cut is finished. And if the metal sheet is slightly curved the Z does not account for that and we end up with a welded torch tip !

Just a heads-up for anyone wrestling with the XHC-WHB04B-6 like I was: relax, it's easier than it looks! Turns out, it's mostly a copy-paste job. My mistake was overthinking it. Make sure your drivers are good to go, create that xhc-whb04b-6.hal file, and pop HALFILE = xhc-whb04b-6.hal into your INI. Then, grab everything from raw.githubusercontent.com/LinuxCNC/linux...ple-configuration.md and paste it in. Tidy it up by removing what you don't need, and if LinuxCNC complains about a line, just delete it until it's happy. Hopefully, this saves someone else the headache!

RE: Toolchange position:

The issue is due to different G7/G8 status for tool changes in the example program. This is solved by forcing 'G8' in the tool change macro.

So change './remap_subs/m6remap.ngc' to this:

Note that this macro is really only a rough sketch as it is, there are likely to be other issues.
Also note that this issue points out that the cgode program needs to set 'G7/G8' _after_ the tool change or, for a fancier solution, for the toolchange macro to restore the 'G7/G8'.

Re: the Z-180 after homing:
Seems your config homes at joint position 200 rather than 0, which is new.

i.e. Z axis travel of 1065mm and home at zero. But after starting and homing z is automatically at -180mm.

Could you attach the ini file? (I notice that you have changed the z-offset to 0)



Re: Toolchange position.
I see this now. I'll need to investigate.

Following this but it seems the same problem has come up again.
Might I be missing a crucial step?
Everything is working as intended, until the encoder come into play...

FYI: Encoders Scale is (1000PPR*4mm/rev)/4=1000

Great! You got it working! I was thinking maybe you had copied files from a CD or something so they could not be written to. But I was in the right area!

I installed an ASRock N100DC-ITX and am very happy with it. It already includes a processor and has the advantage of running on a laptop power supply.
Recommendation from talla83:

I can confirm the stated latency times.
Regards Hermann

i need to set some axis to non Zero values to prevent the kinematics failure,
try to set the 4. and 5. joint to 0.01 and check if the error is gone

Mostly it's a "bang for buck" issue.

I can argue for & against it.

what do you all have against a raspberry pi?
it works well and there are all kinds of cases for it.
2. NIC via USB

Thanks Wischi, now works like it should.
I had not thought to go back to the ini file ! Getting old !

Not sure what you meant by "popup in the right hand corner".
My install starts clean without a pop-up.

I do get a warning when the code reaches the tool change that the bell is not connected (it isn't).
I will soon get a bell, or de-select it.