On Monday, September 12, 2011 06:16:29 AM Mark Wendt did opine:

> On 09/11/2011 06:11 PM, Chris Morley wrote:
> >> Date: Sun, 11 Sep 2011 15:51:33 -0400
> >> From: [email protected]
> >> To: [email protected]
> >> Subject: Re: [Emc-developers] State of documentation ??
> >> 
> >> Jon, et al.
> >> 
> >> I think of this migration of emc2 documentation in terms of three
> >> different activities.
> >> 
> >> 1) transforming the sources of the existing emc2.4 documentation from
> >> lyx to asciidoc form.
> >> 2) reorganizing the documentation.
> > 
> > I think the reorganizing of the docs is due and needs discussion.
> > But i think we need to poll users more the developers on how the docs
> > would be more helpful, ultimately it saves us from answering questions
> > that are in the manual but are hard to find.
> > 
> > from 2.5 HTML
> > 
> > One thing I have noticed is drivers and parallel port  are separate
> > and maybe better if they were all under a heading such as I/O drivers
> > 
> > 'Realtime components' I'm not sure why these particular components are
> > listed on their own.
> > 
> > And really I think the HAL file should be made smaller and be about
> > basic use of HAL and a few of it's tricks for diagnosing problems.
> > 
> > Chris M
> > The rest of HAL belongs in the integrators manual as HAL is mostly
> > what an integrator has to deal with.
> 
> Chris,
> 
> One thing I found, and find frustrating, as a relative noob when it
> comes to things CNC in general and EMC2 in particular, when I was trying
> to get my machine set up and running, was the documentation does a good
> job of listing variables, but it doesn't do a very good job of
> explaining what the variable does, what changing it does, what other
> variables it influences, and how it should be changed when tweaking the
> settings.  I'm talking primarily about the variables found in the .ini
> file, but that also seems to cover the stuff the goes into HAL and the
> hal files also.  It seems that all the stuff is there, but it doesn't
> really describe how each thing works very well.  It would be nice to see
> more examples of how hal file stuff is implemented too.
> 
> I'm a computer system and network admin in my day job, and I'm fairly
> computer savvy (I manage Unix and Linux systems as desktops, servers and
> firewalls).  I've done a fair amount of programming over the years so it
> doesn't scare me to go under the hood, but I got stymied in a lot of
> places because there just wasn't enough talk in the docs about how the
> variables interact with the system, what changing it to a bigger or
> smaller number does (or making it a negative number does), and how
> changing a certain variable may have an effect on how another variable
> does it's job (think acceleration and velocity).  I think that's the
> biggest problems noobs like I had, and what generates a lot of the
> questions.
> 
> Mark
> 
To stick my oar in this water, I agree.  Concise is nice, but when there 
are considerable variables to fine tune, the newbee can easily get lost, 
blinded by the seemingly endless joint errors.

For instance, I just switched from a 4 axis xylotex card to a 4 pack of 
MM-542's.  The xylotex don't do reduced currents when stopped, but the 
MM-542's can be set to drop to 50% current when idle.  I found I had to 
reduce my MAX_ACCEL's about 30% all around, while maintaining a healthy 
headroom cushion of over 30% between the TRAJ settings (slower) and the 
AXIS settings (faster) in order to get rid of the stalls on reverse 
direction startups after an idle period.

I came to the conclusion that the ramp back to full current was taking more 
than a step, and of course if the first step is missed, a stall is going to 
happen.  So I had to slow down the accels as if the motors weren't getting 
full power.  This was based on the fact that I could tap the keys after an 
idle period for a half second and get a stall, but a quickly repeated tap 
always ran normally regardless of which direction the tap was.  On a per 
axis basis.  Moving a different axis was a cold start and stall.

I also found that microstepping at 16x ran much quieter but gave more joint 
errors compared to 8x, but again, reducing the ACCEL's fixed that.  I can 
now run the logo in nearly the same time, and no joint errors are 
encountered at 150% feed rate of 22.5 IPM (same as before) so the slowdowns 
didn't seem to seriously hurt that.

But the docs need to explain this in more detail for the newbee just 
bringing a machine to life for the first time.  And it should include a 
sentence or so about drivers that do reduced idle currents and their effect 
on MAX_ACCEL headroom.

I don't think I will turn the reduced current feature off as the motors 
reduced temps can be easily felt.

As the driver enclosure is largely sealed (its heavy 1/8" and 3/16" alu 
plate) the heat buildup there is going to need a larger, say 8", fan 
blowing on the box to maintain a safe temp inside the box, but this should 
suffice for cooling as there is a big 120 volt, ball bearing "rotron" fan 
circulating the air within the box to encourage the heat transfer to the 
box panels, so the whole box gets warm without noticeable hot spots.  At 2 
hours uptime, I'd guess 15F above ambient without the exterior fan.

Cheers, gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: <http://204.111.66.235:85/gene/>
In less than a century, computers will be making substantial progress on
... the overriding problem of war and peace.
                -- James Slagle

------------------------------------------------------------------------------
Doing More with Less: The Next Generation Virtual Desktop 
What are the key obstacles that have prevented many mid-market businesses
from deploying virtual desktops?   How do next-generation virtual desktops
provide companies an easier-to-deploy, easier-to-manage and more affordable
virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
_______________________________________________
Emc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-users

Reply via email to