Jeff, Thanks for your prompt reply. I need some time to digest your information that I have just read but I do not have any doubt that you must be right and I still have a lot to learn about the internal "mechanics" of EMC and HAL . However, based on actual practical results, I would like to add the following comments:
- Yes, I just changed the indicated values in "setp stepgen.0.steplen" and "setp stepgen.0.stepspace". All other parameters were not changed - As mentioned, I tested FROM stepconf all kind of configurations and timings for len, space and invert without any improvement - This time, to avoid the .hal file being re-written by stepconf, I changed the parameters by hand and tested the machine directly from EMC and OUTSIDE stepconf. Is there any posibility that the problem is from inside stepconf when testing axis? Is just a question. - To check this last point, I will once again use stepconf to configure the system ant I will test it from EMC and not from stepconf. I will keep you aware of results. I do not think (but I may be wrong), that the reason for the problem are related to the other posibilities you mention. As commented I have used two different computers with axactly the same results and the fact is that now both are working perfectly from EMC. To be honest, the only issue I have at the moment is that if I try to use a too much high speed, I get an error message saying "joint # following error", wich is resolved by adjustin the speed. Again, (sorry about this), I do not understand the "joint" concept. I have been working for long time with "axis" and signals (in and out) but not with "joints". Thanks for your patience and your time. Best regards Jesus ----- Original Message ----- From: "Jeff Epler" <[EMAIL PROTECTED]> To: "Enhanced Machine Controller (EMC)" <[email protected]> Sent: Wednesday, December 26, 2007 5:00 PM Subject: Re: [Emc-users] EMC configuration issues On Tue, Dec 25, 2007 at 08:30:09PM +0100, Jesús Bas wrote: > - No matter what numbers you put in stepconf for steplen, step space, > dirhold and dirsetup, the generated .hal file reflect wrong data. I believe that the values written by stepconf are exactly what I intended. Let me explain how stepconf arrives at each figure in question. > In my case, the following requested numbers were (I use Gecko drives): > > - steplen 4000 > - stepspace 500 > - dirhold 20000 > - dirsetup 1000 (not shown: you must have entered a "latency test result" of 30000) > and the corresponding lines in the generated .hal file is allways (no > matter what numbers you input): > > - setp stepgen.0.steplen 1 > - setp stepgen.0.stepspace 0 > - setp stepgen.0.dirhold 50000 > - setp stepgen.0.dirsetup 31000 (not shown: setp parport.0.reset-time 4000) (not shown: inifile BASE_PERIOD of at least 39500) BASE_PERIOD 39500 This is at least as big as machine latency + reset_time + 5000 but may be a larger value if your step rate is low. reset-time 4000 this is the step length you entered in stepconf. After the step "1" bit is written to the parport, it is reset back to "0" after at least 4000ns has passed (but maybe longer) steplen 1 this means "the shortest step length possible". the actual minimum length of the pulse on the parport is 4000ns, defined by parport.0.reset-time stepspace 0 this means that steps are allowed in subsequent base_periods ("doublestep"). The actual minimum length of the space on the parport is defined by BASE_PERIOD - machine latency - reset-time - overhead where "overhead" is any time above and beyond the minimum reset-time that the step pulse is "high", plus any other variations (such as cache misses) that make the time between one "reset" and the subsequent "write" (in the next base-thread invocation) vary. It is assumed that this is less than 5000ns in all cases, but has only been measured on a few machines. dirhold 50000 dirsetup 31000 these are the dirhold and dirsetup values you entered, plus the latency test result you entered. Perhaps someone will point out an error in these calculations, but for now I simply cannot see it. Other possibilities are: * The signal path from your PC to the gecko has other characteristics (e.g., weak drive stringth in the parport, additional external signal conditioning) that lead to increased rise/fall time for signals and require higher step length and space in emc * another error in your configuration, such as an incorrect "invert" on a step output pin * there is a (yet unknown) bug in the hal_parport driver that causes the step output bit to be reset too early (this is based on CPU speed, so if linux misdetects your CPU that could also be the cause) * the arbitrary "max overhead" value of 5000ns is not appropriate for all machines If the *only* change you made was to modify the inifile stepspace to a nonzero value, then the only effect is to increase the step space by approximately one base-period--e.g., from 500ns minimum to 40000ns minimum. The step pulse will still be short (as short as 4000ns) unless you made other changes (e.g., remove the "setp parport.0.pin-##-reset 1" lines, or the "addf parport.0.reset base-thread" line) Jeff ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
