Just my thoughts as a fairly new EMC user. > I strongly disagree with naming _signals_ after things like parallel > port pins. Of course anyone is welcome to name signals whatever makes > sense to them, but IMHO it makes far more sense to name a signal based > on what it _does_, not where it goes. Names like "X-hi-limit" and > "Z-step" are much nicer than "pp2digitalin2". If you want to know what
I have to agree with this one. As a programmer would you define all of your variables as float1 float2 float3 int1 int2 int3 and so on? That tells you what they are but not what they do. IMHO, giving the signals function names helps abstraction as well. You want to keep the physical wiring as far from your internal logic as possible. That way if you change your wiring, all you have to to is move that signal onto the new pin. > I didn't say that anyone would change drivers between major releases. > I was meaning after major releases. TBH, if a driver's pin names change, it is likely that their function may well change as well. In that case, hiding the changes isn't really going to help. > If the user is such a drooler that he can't write a full "net" > command in his custom.hal, he's not going to be able to write half of > one either. Everyone is a newbie at some point. I am a reasonably competent programmer, have used and built CNC machines for years and am familiar with Linux. However I am not that familiar with using emc. If I am a drooler, does that mean ony advanced gods need apply? Every little helps. To be honest, I am still not sure about the syntax of the net command. The docs aren't very clear on the subject. > But that is not how most people do things. They start with some easy > way (stepconf for instance) then when they want more they add a little to > the generated config. then they add more etc. > The jump from generated conf to super advanced config is to much of a > jump. > I read about it all the time. A new giy has to learn linux, ubuntu, > HAL, ini, > Pyvcp classicladder etc. It a lot all at once. Definitely. I am reasonably familiar with Linux but HAL etc are a bit af a learning curve. When you know how to do something, it is easy to forget how much time you spent learning it. > unless something has changed recently, stepconf kills comments. That is a pity and it would be really nice if stepconf could coexist with user's hal file mods. Of course that increases the complexity of stepconf by an order of magnitude and has many potential gotchas. As a user with extra ports, here is what I want to do. Define the port as I/O or all input. Name the pins and/or define them in exactly the same way as the first port. One fairly common use for extra pins is to add an MPG. It would be nice to add that functionality to stepconf. Why limit it to 2 ports? Although I doubt anyone would want more than 3 in total, it strikes me that it would be better to simply define how many ports you have then go through the stepconf pin setup procedure for each port. I don't want much, do i? :-) > Anyways I added the code cause I was there anyways it semed like a good > idea, it was easy and we had time to remove it before it releases. > I sent the email because I wasn't trying to hide what I did nor push an > unwanted idea. Don't take offense. It is very easy to give the wrong impression in an email. Stepconf is a very useful tool and it is good to see you are working on improving it. Les ------------------------------------------------------------------------------ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
