>
> Just my thoughts as a fairly new EMC user.
Thank you for speaking up. The more people give opinions the better.
>
> > 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.
It's not that I disagree with naming signals for what they do. That is the
best way. It's a trade off. Name it something consistent helps newbies
(and us helping newbies), naming it for what it does is self documenting.
But its easy to add comments in the HAL file to clear up what a signal does.
>
> > 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.
Stepconf could add comments about signals in the machine hal file
It also produces a readme that at this point is empty.
( well that was true- I added comments in the readme about the signal
names of the second and third parports )
>
> 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.
I was thinking the standardized signal names would help avoid
people having to change there custom hal file if they changed
the 'prebuilt advanced' options in stepconfig. Maybe it won't
be a problem anyways.
I wanted to add the 'prebuilt' option beacause I have read about
and helped a few people that just wanted a working example
of say a pyvcp panel with a rpm readout. From there they can
figure put how to do more. Then at the same time one guy
wanted to use classicladder to do some fancy thing..well it
took three days of forum emails just to help him get CL loaded!
Now he can just click 'include Classicladder-blank program'
And he has Cl running. From there he can figure out how to
do something else.
>
> 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.
That would make a nice prebuilt example. I will wait to see how the current
ones work out before adding alot more.
> Why limit it to 2 ports?
It's actually three ports right now. It just seemed a reasonable number.
one on board and two on a PCI add on card. Could make it all the way to the
supported 8 but I'd be surprised if many people used more then four.
>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? :-)
See thats a bit of the problem. I didn't add a page to configure the two extra
ports. It just helps you set the address and the type (in/out) and connected
signals to them. Later when time allowed the setup pages could be added.
>
> > 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
I wasn't offended so much as annoyed by the tact on/tact off comment
to me it implied I was being tactless or stupid with my explanation
where I was just trying to explain my idea. Maybe I was over sensitive.
Anyways I'm convinced now. I will remove parport2 and 3 signal name
generating code.
Cheers
Chris Morley
_________________________________________________________________
Drag n’ drop—Get easy photo sharing with Windows Live™ Photos.
http://www.microsoft.com/windows/windowslive/photos.aspx
------------------------------------------------------------------------------
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
