Jon thanks for your reply!
I was using the Pluto-step firmware not the servo firmware so no
encoders are in use.
Additionaly there were no motors connected just the Pluto-p connected
directly to the para port (no cable extention).
The odd thing is when enabling only two axis such as xy or xz or yz it
works ok it's only when at least three axisis enabled within hal the
issue appears!
Sent from my iPhone
On 15 Oct 2010, at 17:47, Jon Elson <el...@pico-systems.com> wrote:
> Jeff Epler wrote:
>>
>> The specific problem you're experiencing is probably an
>> incompatiblity
>> between the EPP protocol implementation in pluto-p and your PC.
> Well, I'm not so sure. I don't know the Pluto at all, but I gather it
> has encoder counters
> on the FPGA. If these encoder counters are accumulators, then I don't
> believe EPP
> mis-communication is the problem. It would cause WILD jumps in
> position
> from sample
> to sample that DO return. What we see in the Halscope trace is
> erratic,
> but SMALL incremental changes
> in position that DON'T return. Now, if the Pluto encoder system
> reports
> deltas every servo period, your
> suggestion makes MUCH more sense. What I mean by deltas is that every
> servo period
> the change in position is reported and the counter is zeroed. The way
> the Pico boards
> do the encoder counter is there is a 24-bit signed counter in the
> FPGA,
> and the absolute
> position is reported every servo period. The driver handles overflows
> to extend range
> beyond 16 million counts.
>
> My take on the trace is that it is motor drive noise getting into the
> encoder inputs.
>> This is one example of the superiority of the Mesa and Pico EPP
>> products--they are designed with appropriate termination on the EPP
>> bus,
>> while the Pluto is not. This means that certain problems on the
>> Pluto
>> board may be due to the board design and simply not fixable in
>> software.
>>
> Early versions of the PPMC and Universal {Stepper | PWM } Controllers
> did not have
> termination. It was only a little problem before PCI parallel port
> boards came out.
> Rev 2.1 (I think) and later boards had the terminators hacked in by
> hand
> at first when
> I discovered this problem.
>
> But, with the non-resetting position accumulators, comm errors would
> show wild
> jumps in position and then return to the correct value next servo
> period.
>
> Jon
>
> ---
> ---
> ---
> ---------------------------------------------------------------------
> Download new Adobe(R) Flash(R) Builder(TM) 4
> The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
> Flex(R) Builder(TM)) enable the development of rich applications
> that run
> across multiple browsers and platforms. Download your free trials
> today!
> http://p.sf.net/sfu/adobe-dev2dev
> _______________________________________________
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
------------------------------------------------------------------------------
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
