> > > It just makes difficult for any observer to understand, what is going on > there. > > If it works and You understand it - very good. But remember that if > You will ever want somebody else to understand it, then it can cause > frustration. I think that in situations like this it is best to stick > to KISS principle (Keep It Simple and Stupid). >
My understanding is that the simple and most well-traveled approach for servo systems with Mesa hardware is to use pncconf. If you have a recommendation for a simpler or stupider solution I am certainly open to it. Personally I have found pncconf to be invaluable and just to clarify, I have not modified the ini or main hal file beyond that generated by pncconf. So if you have a problem with the aliasing, etc. that is an issue with that tool and certainly not of my implementation. If I would do what you suggest and put my changes directly in the hal file, then every change I make in pncconf would require me to manually re-merge my custom changes. AFAIK, the recommended approach for custom hal via pncconf is custom.hal (and custom_postgui.hal), and that is where I have my custom stuff. If the sourcing obfuscates things I apologize, but I don't know a better way to keep configurations relatively modular and still use pncconf. For what it is worth, I believe in the future pncconf is going to use the source command as well for this purpose. > AFAIK having or not having a base thread - yes, it can make a > difference in the realtime performance of Your PC. If I recall > correctly, You had set base-thread to 10000 ns. I am 100% sure that > You are getting realtime error messages. True with that configuration I have under revision control. I typically run at 50000 ns and had set it to 10000 as a diagnostic measure to see if I could increase the sampling rate. Again, though, if I can run a base thread with reasonable performance on all other fronts, why not do that? I am talking about frequency-based analog inputs for things like temperatures and voltage levels where if I miss an encoder count it is certainly not the end of the world. > That is what I told since the very beginning - use encoder module in > 5i23... > You have loaded 4 pwmgens and 4 encoders and are using only 3 of them. > So You a spare encoder module to attach the frequency input to. > I have tried to explain several times why I want a software-based encoder: 1) Eventually I will want more analog inputs. 2) Without a custom firmware I cannot align the encoder with optically isolated I/O. Additionally I'd like to try and build a solution that I can document for anyone to use regardless of specialized hardware. > BTW why do You have 4 stepgens loaded, if You use only one? > That also is a little waste of resources :) If You would load 1 > stepgen, then those pins, currently occupied by 3 unused stepgen > instances would be available as gpio pins. > This would help me conserve a resource that is not at all scarce to me. I have 4 stepgens configured because if I change the number of stepgens pncconf wants me to reconfigure everything. I expect I will want to add a stepper or two in various future machine configurations and so have reserved them in that configuration. The non-isolated I/O alongside the one stepgen in use goes unused otherwise anyway. As You can see, there are bitfiles, that offer 8 encoder modules along > with pwmgens and stepgens. > Yes of course. But as far as I can tell there is no stock bitfile that allows me to run my three main servos and encoders, isolated I/O for limit, etstop, etc. along with isolated I/O for a number of other encoders, a non-isolated stepgen and still make use of the Mesa servo controller card and isolated I/O daughterboard with their specific set of input and output pins. Conversely, if I can get software encoders to work, I can stack software-based encoders using one isolated input each wherever they fit, basically giving me as many as I could ever need. Regards, Scott ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
