My base thread is 20000 ns (50 khz) and my servo thread is 1000000 ns. I am running the update-counters in the base thread. I was thinking that should limit my sampling noise to ~2% but instead it is ~20%. I don't think I'm getting bounce errors as the parallel port pins in halscope show regular pulses as I would expect. To understand this issue better, I've set up the following standalone hal configuration:
****************** loadrt threads name1=base-thread period1=20000 name2=servo-thread period2=1000000 loadrt probe_parport loadrt hal_parport cfg="0x378 out " setp parport.0.reset-time 5000 addf parport.0.read base-thread addf parport.0.write base-thread addf parport.0.reset base-thread loadrt encoder num_chan=1 loadrt lowpass setp encoder.0.counter-mode true net encoder-0-phase-A encoder.0.phase-A <= parport.0.pin-10-in setp encoder.0.position-scale 1.0 addf lowpass.0 servo-thread setp lowpass.0.gain 0.001 net lowpass-0-in lowpass.0.in <= encoder.0.velocity net temp-0-in-filtered <= lowpass.0.out addf encoder.update-counters base-thread addf encoder.capture-position servo-thread start ****************** that I kick off like so: halrun -U sudo /etc/init.d/realtime restart halcmd -f thermal-input.hal halmeter & and added some logging to the encoder.c component and installed it via: sudo comp --install encoder.c and then I see the my additional error-level logging in /var/log/messages As an aside, I was astounded how easy it is to develop (or at least modify and debug existing) c-level components. Great job to all who have made that system what it is. I thought it might take me days to get a re-compiled encoder.c component working and was pleased to find it was actually only minutes. Doing that showed me that although the base thread runs were sufficient in number and capturing the transitions properly, there actually was variance between the between-rising-edge times it was catching, ranging in a short sample from 817us to 1173us for what should be a fairly steady 1khz/1000us signal. Modifying the encoder component to have it log a count of update runs between pulses shows anywhere from 40 to 60 runs between a rising edge detection, but always averaging right at 50 and typically subsequent intervals compensating for the previous intervals in terms of overall time. For instance, an interval with 45 base thread runs between a rising edge detected would be followed by an interval with 55 base thread runs. This is leading me to wonder about timing in the parport driver. I see there is a reset function for pushing values faster, but it seems like that is for output. Is anyone aware of how input data propagates through the parport driver and if there are opportunities for delay? Thanks much, Scott ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
