1988 Fadal 4020 Conversion Thoughts: MESA 6i24 + 7i49 + ?

More
6 years 3 months ago #176316 by andypugh

hilo90mhz wrote: Oh and I did also just remember that I could use these DC drives in torque mode by disconnecting the tachometers. Someone did this with a Kflop conversion of the same mill with the same drives - by cutting a resistor lead and soldering a wire onto said resistor past the velocity feedback loop on the drives.

Does anyone have insights on if I would be better off bypassing the tachometers like this?


I think you would be best leaving the tachometers connected. Velocity mode is typically a lot easier to tune and has a faster inner hardware loop than the LinuxCNC software loop. Keep this idea in reserve in case of the unlikely event of a tachometer failure.
The following user(s) said Thank You: hilo90mhz

Please Log in or Create an account to join the conversation.

More
6 years 3 months ago #176319 by hilo90mhz
I want the extra bit of accuracy from the resolvers - just moving it to the marks is not very accurate for repeatability with fixture setup etc.

I'll have to look into those options with the resolver drive but sounds like its possible at least.. It seems like this sort of feature would be something anyone with resolvers might want to take advantage, with a free built in homing setup that is as accurate as the resolver is and not vulnerable to power loss etc.

Please Log in or Create an account to join the conversation.

More
6 years 3 months ago #176320 by andypugh

andypugh wrote: I think that, compared to my lathe, it is harder to use the marks than to use the full-absolute emulation.


See "joint-pos-fb" in the resolver docs here: linuxcnc.org/docs/2.8/html/man/man9/hostmot2.9.html#resolver

Using the position.txt data from the previous run, the system acts much like with the marks you describe, except using the shutdown position in place of the mark.
This will only work for Z if the head does not drop after linuxCNC exits.
The following user(s) said Thank You: hilo90mhz

Please Log in or Create an account to join the conversation.

More
6 years 3 months ago - 6 years 3 months ago #176321 by hilo90mhz

andypugh wrote: Using the position.txt data from the previous run, the system acts much like with the marks you describe, except using the shutdown position in place of the mark.
This will only work for Z if the head does not drop after linuxCNC exits.


This sounds better than nothing :D but what If I spin the motors a little by hand while it is off? theres no way to find that exact home position ever again which isnt good enough for me ;)

Actually now that I look at it more this is great and should be a good starting point for what I wanted to have happen with the marks, so as long as the source code for that module that runs on the FPGA board is available etc.

Z does not normally drop if gibs adjusted properly, it has giant counterweights on it.
Last edit: 6 years 3 months ago by hilo90mhz.

Please Log in or Create an account to join the conversation.

More
6 years 3 months ago #176360 by andypugh

hilo90mhz wrote: This sounds better than nothing :D but what If I spin the motors a little by hand while it is off?

Just don't? :-)

theres no way to find that exact home position ever again which isnt good enough for me

What I have for my lathe is an alternate INI file that sets things up with conventional homing. If I lose home (through something going wrong which leads to the position.txt file being wrong) then I re-start the machine from that config and home conventionally.
(I can then continue to use the machine normally, then when I re-start with the auto-homing config everything is sorted out again)

Alternatively you might be able to setp the joint-pos-fb pin of the resolver module to a fixed position and use a GUI button to toggle the resolver.N.use-position-file parameter. That might well leave you with exactly the current behaviour.

Note that it is a parameter, so it isn't a simple HAL link, it would need to be set by a little script (see the M100-M199 docs for examples).

Here is the code:
github.com/LinuxCNC/linuxcnc/blob/master...mot2/resolver.c#L354

If it looks like toggling the use-position-file input (internally called use-abs) would do what you want then it is relatively easy for me to change that parameter to be a full HAL pin.
The following user(s) said Thank You: hilo90mhz

Please Log in or Create an account to join the conversation.

More
6 years 3 months ago - 6 years 3 months ago #176406 by hilo90mhz

andypugh wrote: Here is the code:
github.com/LinuxCNC/linuxcnc/blob/master...mot2/resolver.c#L354

Edit: Okay I realized my mistake - this is not the firmware source but the driver source that runs on the LinuxCNC computer and interacts with the firmware on the Mesa 7i49..

That is great that the Mesa firmware source is actually part of the LinuxCNC source! I did not realize the product was so fully integrated with LinuxCNC - got to give props for Mesa for this! Am I correct in thinking that all of the Mesa firmware source code is open source and just the hardware design files are closed source then? Not that I plan to duplicate the Mesa hardware - the price points of the Mesa boards are very reasonable for what they are.

andypugh wrote: If it looks like toggling the use-position-file input (internally called use-abs) would do what you want then it is relatively easy for me to change that parameter to be a full HAL pin.

Awesome! I'm still wrapping my head around how all the different layers in LinuxCNC interact but may take you up on that if its the easiest solution. I will get back to you once I've gone through the setup and understand how the entire LinuxCNC environment works more if this turns out to make the most sense vs using the M100-M199 script method to set it.

Okay think I'll pull trigger on the 7i49 now... Get it all working with current motors/drives..
Last edit: 6 years 3 months ago by hilo90mhz.

Please Log in or Create an account to join the conversation.

Moderators: PCW, jmelson
Time to create page: 0.251 seconds
Powered by Kunena Forum