Back
[00:16:25] <KGB-linuxcnc> 03john 05unified-build-candidate-3 755c41f 06linuxcnc 10src/ 10Makefile 10hal/Submakefile 10rtapi/.gitignore 10rtapi/Submakefile * Fix make -j16 build breakage caused by multiple problems
[00:29:13] <linuxcnc-build> build #1309 of hardy-amd64-sim is complete: Failure [4failed install-missing-build-dependencies] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/1309 blamelist: dummy, John Morris <john@zultron.com>
[00:29:24] <linuxcnc-build> build #1305 of hardy-i386-realtime-rip is complete: Failure [4failed install-missing-build-dependencies] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/1305 blamelist: dummy, John Morris <john@zultron.com>
[00:29:52] <linuxcnc-build> build #1307 of hardy-i386-sim is complete: Failure [4failed install-missing-build-dependencies] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-sim/builds/1307 blamelist: dummy, John Morris <john@zultron.com>
[01:07:49] <linuxcnc-build> build #1303 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1303 blamelist: dummy, John Morris <john@zultron.com>
[11:25:35] <pcw_home> andypugh: how about a bigger string like:
[11:25:36] <pcw_home> bits34unused2graycount12unused2binturns12statusa1crc5
[11:27:20] <andypugh> The only problem I see with that is that the hm2 config string tends to end up quite long anyway, and I don't think it can wrap. I admit that isn\t aparticularly strong reason.
[11:28:23] <andypugh> As a first step along this road, the smart-serial encoder counters maybe about to grow a simulated index
[11:29:23] <andypugh> (the other option is that I invent a new smart-serial pin type.
[11:30:08] <andypugh> Version 1.8 of the 8i73 manual doesn't mention DATA_TYPE 0x08 (encoder) by the way, despite the 7i73 having ome.
[11:30:16] <andypugh> (some)
[11:31:06] <pcw_home> We will have an encoder index on some remotes as well
[11:31:36] <andypugh> Is that a different DATA_TYPE code?
[11:31:50] <pcw_home> It probably will have to be
[11:32:12] <andypugh> Any spec?
[11:32:38] <andypugh> Shall I assume DATA_TYPE 0x09 or is that taken?
[11:32:46] <pcw_home> not yet but we have a remote spindle control sserial thingy that has encoder built in
[11:33:26] <andypugh> Any plans for smart-serial absolute-encoder interfaces?
[11:34:08] <pcw_home> 0x09 is likely but we have to decide what to do about index.latched count,index enable and crew
[11:34:54] <andypugh> Indeed.
[11:35:24] <pcw_home> probably, Smart serial thats built into cards can run at 10 MB/s or higher so more data is possible
[11:37:44] <pcw_home> we are aslo adding new RX and TX RPCs so the RX data phase can be separate from the TX phase
[11:37:45] <pcw_home> this allows more up-to-date RX data since the RX transfer cycle can now be started by the timer
[11:37:47] <pcw_home> (same situation fo SSI, BISS,SPI etc)
[11:37:49] <andypugh> If I want to re-use the smart-serial bit-stream parsing and variable pin creation scheme for the absolute encoders (and that seems to make a lot of sense) then either the existing encoder gains a simulated index, or we have a different DATA_TYPE for abs encoders (and then a different one again for encoders with an actual index)
[11:38:36] <pcw_home> well there are lots (255-8) of available data types...
[11:38:59] <andypugh> Indeed, we just need to agree on them :-)
[11:40:28] <pcw_home> It is a nice way to request special handling though i wish we had spilt the dat format from the driver data handling hint
[11:40:44] <andypugh> absolute encoders need a simulated index for LinuxCNC to undestand them (for spindle-synchronised moves and index-homing).
[11:40:53] <pcw_home> Yes
[11:41:24] <pcw_home> and simulated index is a nice add on for all encoders as long as you understand the limitations
[11:41:30] <andypugh> I might as well add a simulated index to the existing encoders
[11:41:37] <pcw_home> Ha
[11:41:47] <andypugh> It actually makes my life easier.
[11:41:56] <andypugh> Pin, Param or hidden?
[11:43:51] <pcw_home> param to enable?
[11:45:21] <andypugh> I have an unused param in the generic sserial structure, I will use that and pre-load it with data_length^2 in sserial. For abs encoders I can't decide if folk need to set the param themselves or whether the loadrt string parser should tweak it afterwards.
[11:45:48] <andypugh> Sorry, to set how often the index is triggered.
[11:46:30] <andypugh> As in how many counts per index
[11:47:19] <andypugh> The sserial encoder is also going to have to gain a scale parameter too, though that is no bad thing.
[12:02:29] <pcw_home> Yeah no reason they should be different
[12:05:04] <pcw_home> encoder bit fields specifiers should be useable for almost all absolute encoder types
[12:07:28] <andypugh> I think this is one of those things that might have to be released then we can see how folk break it.
[12:08:18] <pcw_home> I have this disturbing thought that we are slowly re-implementing CAN :-)
[15:30:27] <andypugh> pcw_home: Do you see any problems with over-riding the data direction on type 0x08 devices? Is it fair to assume that an encoder will always supply a value to HAL and that index-enable is IO and scale is a param?
[15:30:56] <andypugh> ie, do you imagine there ever being an _output_ version of the encoder?
[15:37:44] <pcw_home> I dont think we've dealt with bidirectional signals yet
[15:39:13] <pcw_home> not that theres anything wrong with them
[19:03:35] <andypugh> Does anyone have a favoured way to spot encoder wrap? I am thinking of using:
[19:03:35] <andypugh> if ((i - old_i) * (old_i % 1000 - i % 1000) > 0)
[19:04:01] <andypugh> But perhaps that is computatuonally inefficient.
[19:05:17] <andypugh> (this is the case where the counts are already promoted from an arbitrary bit length into a 64 bit accumulator, and the nominal index is every N counts, 1000 in the example)
[19:07:51] <andypugh> Checking abs(old_i % N - i % N) > N/2 is probably more common.
[19:08:23] <andypugh> And I guess an abs is easier than a multiply.
[21:15:37] <andypugh> Well, all moot, I can't mod as s64 by a u32 anyway.