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

More
29 Jul 2020 00:19 - 29 Jul 2020 00:30 #176312 by hilo90mhz
Thanks Jon, now that you say it that makes perfect sense that the update rate is based entirely on the electronics reading the analog values as the sensor is purely analog...

Do you have anymore information online about the Analog Devices 2S1200 based converter you make?

www.mouser.com/datasheet/2/28/11BRW-300-F1-6-958427.pdf
I have read the resolver datasheet more now and see that it specifies "max error from E Z: +/- 6 minutes" which I assume means it has +/- 6 arc minutes per revolution accuracy? The transformation ratio is 0.5 (I originally thought it was 1/6th but that was the accuracy of 6%).

My ball screws are 0.2" per revolution.
Calculations to determine accuracy based on datasheet:
6 arc minutes accuracy = .1 degree
360 / 0.1 = 3600 points per revolution accuracy
.2" / 3600 = 0.000188" or 0.00477mm or 4.77um accuracy
Does this makes sense?

I am okay with that accuracy

My resolvers are rated for 2500hz - do you know what this means and if they should not be operated at any other frequency? less linearity at other frequencies?

You are right I should probably not worry about the motors/brushes too much in a non high volume production environment, this will be used for prototype development work and low volume production.. Accuracy is important. That just leaves the DC drives which are repairable / replaceable with modern equivalents..

I'm still about 50/50 with replacing vs keeping these motors / drives, leaning slightly towards keeping them right now.
Last edit: 29 Jul 2020 00:30 by hilo90mhz.

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

More
29 Jul 2020 00:29 #176313 by andypugh

Is there an easy way for me to do this same setup that Fadal used with the alignment markers on LinuxCNC?


You can just set up LinuxCNC for immediate homing. Then you can power-up, jog to the markers and press home. That will give you accuracy as good as the marks.

To get the extra bit of accuracy from the resolver absolute position might take some experimentation with the "home absolute encoder" INI options and the absolute pins of the resolver driver.
I think that, compared to my lathe, it is harder to use the marks than to use the full-absolute emulation.
The following user(s) said Thank You: hilo90mhz

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

More
29 Jul 2020 00:32 #176316 by andypugh

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
29 Jul 2020 00:34 #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
29 Jul 2020 00:36 #176320 by andypugh

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
29 Jul 2020 00:41 - 29 Jul 2020 00:51 #176321 by hilo90mhz

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: 29 Jul 2020 00:51 by hilo90mhz.

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

More
29 Jul 2020 11:36 #176360 by andypugh

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
29 Jul 2020 20:25 - 29 Jul 2020 20:27 #176406 by hilo90mhz

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.

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: 29 Jul 2020 20:27 by hilo90mhz.

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

More
29 Jul 2020 20:32 - 29 Jul 2020 20:32 #176408 by andypugh

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..


Yes, you need to look here for the Mesa source:
github.com/LinuxCNC/hostmot2-firmware/bl...ter/src/resolver.vhd

(And this firmware would run on the 6i24, the 7i49 is essentially passive)
Last edit: 29 Jul 2020 20:32 by andypugh.
The following user(s) said Thank You: hilo90mhz

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

More
29 Jul 2020 20:46 - 29 Jul 2020 20:47 #176411 by hilo90mhz

Yes, you need to look here for the Mesa source:
github.com/LinuxCNC/hostmot2-firmware/bl...ter/src/resolver.vhd
(And this firmware would run on the 6i24, the 7i49 is essentially passive)

I had just found that repository ;) - I notice the most recent commit is 4 years old, does that mean there have been no updates to the firmware since then? or just not merged from some upstream Mesa source?

(And this firmware would run on the 6i24, the 7i49 is essentially passive)

Of course you are right! and I knew that just wasn't thinking about it fully..

Do you recommend using shielded 50 pin IDE cables? for connections between FPGA and daughter boards? I can shield them myself with conductive fabric style tape but not sure its necessary.

-Chester
Last edit: 29 Jul 2020 20:47 by hilo90mhz.

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

Moderators: PCWjmelson
Time to create page: 0.249 seconds
Powered by Kunena Forum