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

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.

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.

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

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

andypugh wrote:

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?

andypugh wrote:

(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