Roland Jollivet wrote: > I see. And is the time stamp used as an integral part of the EMC > calculation? Or rather, does the Pluto interface for example, also supply > the same info? > > What I'm also wanting to know is; > If a system has 4 axis, that's 4 x (4x8) bytes to read per sample (=128 > bytes) > Math error! :) You don't read (4*8) bytes per axis, it's 4 bytes or 4*8 bits. At least for the encoders on a Mesa system. Reading 4 encoders at 32 bits each is 16 bytes, which takes around 16 microseconds over EPP (it's a couple of microseconds for any reasonable PCI system). > Is it practical(for a low cost encoder board) to have only 8bits per > encoder. Since each sample is now only a 4 byte read, the sample rate could > be far higher, and the hardware becomes a lot simpler. > A 4 byte read is only 4 bytes less than an 8 byte read, and it only saves around 4 microseconds over an EPP bus. The reduction in possible count rate is pretty terrible.
You would have to increase the servo cycle rate (or at least the encoder read rate) by a factor of 256 to be able to support the same count rates as a 16-bit encoder register. That involves 256 times the number of bytes being transferred. By making the read take twice as long, you don't have to increase the rate at which that thread runs, and the total number of reads is actually around 1/128 as much. In other words, a 16-bit count is enough that you can use a 1-2 ms servo cycle without really being concerned about a counter overrun. If you reduced the count to 8 bits, you would need to read the encoder register 256 timed as often to support the same count rate. Say your encoder will only move 2000 counts in 1ms. An 8-bit counter can only count +127/-128 counts, so you would need to read an 8-bit encoder counter16 times every millisecond to just barely handle that rate. You're reading 1 byte16 times instead of 2 bytes one time. Loads more data transfer needed for the "simpler" case. - Steve ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
