2012/3/18 Chris Morley <chrisinnana...@hotmail.com>: > >> 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. >> > > I think the biggest problem here Scott is the most experienced users / > developers > don't use PNCconf and few use the advanced features you are using. > It is considerably easier to debug a problem if the config is similar to > what they have usually seen.
Thanks, that is what I tried to explain. Scott, whatever way You get Your machine to work the way You need it, is perfect. My point is that You should be aware - it is hard for anybody else (like me) to step in and find, what might be wrong there, if You have set things up in a different manner. Just like Chris mentioned, aliasing amd sourcing is something I have never seen, so my first suggestion, when I looked at Your config was: the problem is that analog-in.hal is not specified in INI file, so it is not loaded at all. 2012/3/18 Scott Hasse <scott.ha...@gmail.com>: > > 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. > Some of available firmwares can have 8 encoder modules. 3 are used for servos, so You have 5 left for analog inputs. I myself am creating those flat ribbon cables by cutting of the length I need and then attaching the connectors. And one thing I have learned - it is easy to create a custom cable, where pins are rearranged as needed (attach each 50-pin connector to a separate piece of cable and then solder them in the middle pin by pin in the required order so that isolated inputs from 7i37 go directly to each encoder module). > 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. And why not? For example, SVST8_4 firmware: 4 encoders and 4 pwmgens on connector P2 - for Your servos 4 encoders on connector P3 - use them for analog in, remaining are gpio pins 4 stepgens on connector P4 - 4 stepgens Connect 7i37 to P3, rearrange the pins in the cable, going to 7i37, so that 4 inputs go to each of encoders, remaining 12 inputs go to GPIO pins (for limits etc), which are available there, if only 4 or less pwmgens are loaded. And that is it. You still have pwmgens and encoder modules for servos, stepgens on another connector and 4 encoders along with 12 gpio pins on third connector for 7i37's 16 optoisolated inputs. Scott, I am just trying to show, that it is doable. I am not trying to convince You to do it only and exactly this way by any means. Well, ok, I am trying to convince You to _try out_ using encoder module on Mesa card, so that You know, how both options are working and then You can make much better decision, which solution to choose. Viesturs ------------------------------------------------------------------------------ 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 Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
