#emc-devel | Logs for 2006-11-12

[01:20:01] <SWPLinux> ok, now this is weird. I've transferred the dropbox files to linuxcnc.org/dropbox, but I get an error when trying to download some files
[01:20:07] <SWPLinux> like cam.py
[01:20:34] <SWPLinux> I even created a cam.py.tgz, in case it's trying to execute the file as CGI or some silly thing, and that doesn't work either
[01:20:54] <SWPLinux> I checked permissions and wonership, and they'er all the same between files that work and ones that don'y
[01:20:54] <SWPLinux> don't
[01:22:22] <jepler> [Sat Nov 11 17:18:41 2006] [error] [client] Premature end of script headers: /home/cncman/www.linuxcnc.org/dropbox/cam.py.tgz
[01:22:24] <jepler> it's still treating it as a script, apparently
[01:22:32] <SWPLinux> how odd
[01:22:53] <jepler> rename to cam_py.txt?
[01:22:55] <SWPLinux> ok - I renamed it to cam.tgz, and I can now download it
[01:23:55] <SWPLinux> I wonder if I can fix that behavior with a .htaccess file
[01:25:19] <SWPLinux> I suppose I can set everything to application/octet-stream, and it'll force download of any file in the dropbox
[01:25:29] <SWPLinux> not too convenient for the images, text, and html files though
[01:29:01] <SWPLinux> well, at least it's nice to know we can do automatic python scripts on DH
[02:57:52] <SWPLinux> hi, virtual jmk
[02:58:03] <jmkasunich> hi
[02:58:24] <jmk-vm02> actually, hi
[02:58:33] <SWPLinux> that's better
[02:58:39] <jmk-vm02> breezy install
[02:58:43] <SWPLinux> things were starting to seem real for a seconf there
[02:58:56] <jmk-vm02> for some reason I had to do a ifup to get the network to connect
[02:59:10] <SWPLinux> on the host or the guest?
[02:59:12] <jmk-vm02> guest
[02:59:27] <SWPLinux> have you installed the guest tools?
[02:59:32] <jmk-vm02> no
[02:59:35] <jmk-vm02> (not yet)
[02:59:42] <jmk-vm02> * jmk-vm02 reads the manual
[02:59:50] <SWPLinux> try that, and also you may find that a "reboot" fixes it
[03:00:15] <SWPLinux> (a reboot of the guest, of course)
[03:00:48] <jmk-vm02> right
[03:04:24] <SWPLinux> question: I'm writing a "uint-to-bit-array" converter - do you think it's worthwhile to have an offset parameter (so you can output something other than the N lowest bits)?
[03:04:44] <jmk-vm02> I suppose
[03:04:46] <SWPLinux> heh
[03:04:52] <jmk-vm02> that wouldn't be a hal param
[03:05:07] <SWPLinux> I was thinking it would be
[03:05:14] <jmk-vm02> because it probably would want to control the exporting of pins
[03:05:39] <jmk-vm02> insmod param like firstbit=5 lastbit=9
[03:05:40] <SWPLinux> right - there's an insmod parameter to tell how many bits to output for each one
[03:05:45] <jmk-vm02> or something like that
[03:05:49] <SWPLinux> I just have an array of N for each one
[03:06:01] <SWPLinux> but I was thinking that it may be useful to offset N
[03:06:06] <jmk-vm02> N hal pins?
[03:06:09] <SWPLinux> yes
[03:06:18] <jmk-vm02> so currently you are passing one insmod param, N
[03:06:30] <SWPLinux> with the converters Jeff wrote, this will just have a U32 input
[03:06:35] <jmk-vm02> how are you naming the pins? if there is an offset, don't the pin names change?
[03:06:46] <SWPLinux> yes, though it's an array, since there can me several converters
[03:06:53] <SWPLinux> no, I wouldn't change them
[03:07:05] <jmk-vm02> I'm glossing over the 'several' issue
[03:07:15] <SWPLinux> the reason for an offset would be to shift something into the lower bits
[03:07:18] <SWPLinux> ok - we can ignore array things
[03:08:07] <jmk-vm02> if you are gonna shift things so that bit 11 comes out pin 0, why don't you call that pin 11?
[03:08:37] <SWPLinux> well, because it's the lowest bit being output
[03:08:56] <jmk-vm02> hmm, I wonder if a nicer (maybe not easier, but who knows) way would be a u32 that is a mask
[03:09:14] <SWPLinux> hmmm - maybe
[03:09:21] <jmk-vm02> if you want to export bits 0-3, and bit 8, you say "mask=0x10F"
[03:09:26] <SWPLinux> sure
[03:09:46] <jmk-vm02> and it exports pins called "bit-0, bit-1, bit-2, bit-3, and bit-8"
[03:09:58] <SWPLinux> yeah - that's the part I don't like
[03:10:07] <jmk-vm02> why not?
[03:10:27] <SWPLinux> I see this partly as an abstraction from the actual bit locations in the source int
[03:10:55] <jmk-vm02> so how _are_ you going to label them?
[03:11:16] <SWPLinux> consider something like a multi-value gain stage, where you want the few high bits to control the amp
[03:11:31] <SWPLinux> I'd name them as bit-0, bit-1 ..., using only the ones that get output
[03:11:53] <jmk-vm02> but that just introduces ANOTHER numbering scheme, that means absolutely nothing at all
[03:11:57] <SWPLinux> so in the mask=0x10F case, you'd have bit-0 through bit-4, and bit-4 would be bit 8 from the source
[03:12:14] <jmk-vm02> how can that possibly make things clearer?
[03:12:18] <SWPLinux> heh
[03:12:35] <jmk-vm02> remember - you can name the signals that are connected to those pins whatever you want
[03:12:36] <jmk-vm02> and you should
[03:12:55] <jmk-vm02> for example, you could reorder the bits by crossing the signal wires
[03:13:08] <SWPLinux> well, in the case of a DAC with gain, I may change to a 12-bit DAC from a 10bit, so I change the bit positions I want to go to the gain stages
[03:13:31] <SWPLinux> but I don't want to change the hal files, I still have gain-0, gain-1 ...
[03:13:39] <jmk-vm02> well, IMO if you are using this to control a dac, something is seriously wrong
[03:14:37] <jmk-vm02> (should be using a driver that implements the canonical dac, not messing about with bits)
[03:14:57] <jmk-vm02> but thats a digression
[03:15:02] <SWPLinux> hmmm - consider sign for a moment
[03:15:08] <jepler> It's not that unreasonable for a hobbyist. You rig up a little R-2R ladder on the parport, and you have to do that kind of crap to hook it up in hal
[03:15:40] <SWPLinux> true
[03:15:43] <jmk-vm02> if you want to connect your R-2R to the output of PID, for example, that is a float
[03:15:53] <jepler> jmk-vm02: sssssshhhhhh
[03:15:57] <SWPLinux> heh
[03:16:18] <jmk-vm02> so you're gonna need to scale it, and clamp it, so the resulting binary value is 00-FF
[03:16:55] <SWPLinux> sure, but you may have a scaler (analog op-amp type thing) that's controlled by output bits
[03:17:44] <jmk-vm02> ok, so you have 00-3F for a 6 bit ladder, and one bit for "gain x2", and one more for "make output negative"
[03:17:53] <SWPLinux> yep
[03:18:27] <jmk-vm02> so - you gotta convert the float into a signed int, then take the high bit and use it for sign, and the next 6 for magniture
[03:18:30] <jmk-vm02> ude
[03:18:37] <jmk-vm02> really have no clue how you'd use the scaler thing
[03:18:45] <cradek> well good grief
[03:18:57] <jmk-vm02> that's a recipe for glitches, if you switch it based on the signal level
[03:19:07] <SWPLinux> right, and when you improve the ladder to a 12-bit one, the sign and magnitude bits will be in different positions
[03:19:20] <jmk-vm02> so you reconnect them in hal
[03:19:37] <SWPLinux> but with my scheme, you'd only output those two bits with this component - the lower bits would be used welsewhere (possibly in a separate one of these)
[03:19:42] <SWPLinux> yep
[03:19:53] <SWPLinux> obviously, it can work either way
[03:20:13] <SWPLinux> I prefer to give N output bits, numbered 0-(n-1), regardless of where they come from
[03:20:32] <jmk-vm02> I guess we agree to disagree
[03:20:35] <SWPLinux> heh
[03:20:51] <jmk-vm02> if we're picking bits out of a larger word, why introduce another numbering scheme that means absolutely nothing?
[03:21:14] <SWPLinux> it doesn't mean nothing
[03:21:21] <jmk-vm02> yeah it does
[03:22:14] <SWPLinux> I'm thinking of this as a bitfield extractor, so if you have a word that has several things in it, like a status word, you can strip out pieces of it, and each one has its separate bits 0-N
[03:22:32] <jmk-vm02> sometimes, you might get lucky, and actually want to use the bits you pulled out as part of a word, and maybe you'll even be lucky and the order of the bits in the new word you are building will match the order in the old word
[03:22:52] <jmk-vm02> so for each bitfield, you need another instance of this widget
[03:22:56] <SWPLinux> yep
[03:23:10] <jmk-vm02> the mask approach lets you pull all the bits you want with one widget
[03:23:27] <jmk-vm02> need, 0-3, 8-11, and 22-30, no prob
[03:23:46] <SWPLinux> again, it's abstraction or no abstraction
[03:23:57] <jmk-vm02> the abstraction comes from the signal names
[03:24:19] <jmk-vm02> you connect signals with meaningfull names to the pins of the extractor component
[03:24:40] <SWPLinux> this is similar to the discussion about naming ppmc parts - whether they should be bus.slot.whatever vs. whatever-(ascending N)
[03:24:58] <jmk-vm02> yeah, and in hindsight I regret the ascending N approach
[03:25:02] <SWPLinux> heh
[03:25:08] <SWPLinux> then we agree to disagree ;)
[03:25:45] <jmk-vm02> adding a new card should not result in all the existing connections getting silently re-routed
[03:25:56] <jmk-vm02> which is what the current approach will do
[03:26:08] <jmk-vm02> (if the new card comes before the existing one)
[03:26:44] <jmk-vm02> if the mapping between pins and signals is in the HAL file, it is clear and documented
[03:26:52] <SWPLinux> hmmm - on a tangent, if you specify parallel ports in a different order, does the bus number change (even if no cards are found on the other buses)?
[03:26:55] <jmk-vm02> show pin or show sig will tell you exactly what you have
[03:27:13] <jmk-vm02> not sure
[03:27:27] <jmk-vm02> I think if a bus is completely empty, that is treated as an error and the driver won't load
[03:27:31] <SWPLinux> ie, you have a ppmc connected to 0x378 - what happens if you specify "0x278, 0x3bc, 0x378", but don't move the card?
[03:27:36] <SWPLinux> ok
[03:28:07] <jmk-vm02> back to the splitter
[03:28:17] <SWPLinux> yep
[03:28:25] <jmk-vm02> I think the insmod line shold tell you _only_ what bits are going to be extraced
[03:28:36] <jmk-vm02> and the HAL linksp stuff tells you where they go
[03:29:21] <SWPLinux> I guess it doesn't matter, but my thought was that if you want to output 6 bits, starting at bit 3 (through 8), then you probably want the output to be bits 0-5, not 3-8. otherwise, I might as well export all 32 bits every time
[03:29:22] <jmk-vm02> if changing the insmod params changes the mapping between bits in the large word, and HAL pin names, then the "where they go" info is controlled only partly by the linksp stuff
[03:29:38] <jmk-vm02> why do you assume you want 0-5?
[03:29:54] <jmk-vm02> maybe I have 6 completely independent things packed in there
[03:30:07] <SWPLinux> sure, and numbering them 0-5 is fine in that case
[03:30:18] <jmk-vm02> maybe bit 8 is a sign bit, and I want to connect it to a signal called "sign"
[03:30:29] <jmk-vm02> no its not
[03:30:57] <jmk-vm02> if somebody is reading the hal file, or examining the running system, how do they figure out what bit of the word is driving your pin "2"?
[03:31:16] <jmk-vm02> they need to look up the docs for the extractor, understand the insmod params that are being passed to it, etc
[03:31:41] <jmk-vm02> that is far less discoverable than if the pins are named based on what bit of the original word they are connected to
[03:31:49] <SWPLinux> well here's the thing - the meaning of the bits depends entirely on the source of the bits, so there's no way we can decide which is better
[03:31:57] <SWPLinux> sure, I can agree with that
[03:32:11] <jmk-vm02> then the exact format of the insmod param is almost irrelevant - just doing a show pin will show you exactly what you have
[03:32:24] <jmk-vm02> you only need to go learn the insmod param format if you need to change it
[03:32:37] <SWPLinux> that's true
[03:33:04] <SWPLinux> hmmm - I guess what I'm thinking about is more useful in the context of a hardware driver
[03:33:04] <jmk-vm02> discoverability is an important goal for me
[03:33:36] <SWPLinux> though the idea of moving data around in HAL (like for a serial packetizer) would be better served with the from-zero numbering, I think
[03:34:08] <jmk-vm02> not sure I understand what you are saying
[03:34:29] <SWPLinux> well, consider a generic serial driver that just exports some bytes, words, and longs
[03:34:49] <jmk-vm02> thats too damn generic IMO
[03:35:01] <SWPLinux> use a few of these components to extract "digital-in-0 through digital-in-N" as bits
[03:35:02] <jmk-vm02> but I'll go along for the moment
[03:35:27] <SWPLinux> you really don't want to care if the serial format changes (unless you're the one writing the .hal file "driver" for it)
[03:35:47] <jmk-vm02> IOW, the hardware lumps the dig ins into a word, and sends it serially... then the driver dumps the word into HAL, and you use the extractor to get the individual bits?
[03:35:55] <SWPLinux> yep
[03:36:02] <jmk-vm02> retch
[03:36:05] <SWPLinux> heh
[03:36:37] <SWPLinux> a system of that type wouldn't need a driver to be written for it - just a hal file
[03:36:41] <jmk-vm02> that means the hal file author needs to know how the hardware packs the bits
[03:37:07] <SWPLinux> yes, but since you can specify multiple hal files in the ini, the "vendor" can just provide a hal file with the hardware
[03:37:11] <jmk-vm02> IMO, there _should_ be a driver written for it, specifically to hide the details of how the bits are packed
[03:37:31] <SWPLinux> (this only works well once we separate instantiation from loading of HAL components)
[03:37:53] <jmk-vm02> any hardware that doesn't provide a driver implementing the appropriate canonical interface is defective IMPO
[03:37:53] <jmk-vm02> IMO
[03:38:09] <SWPLinux> In Your Professional Opinion ;)
[03:38:18] <jmk-vm02> in my typo opinion
[03:38:21] <SWPLinux> heh
[03:40:20] <jmk-vm02> if the hardware is using a "standard" serial interface layer, then all the vendor needs to write is the packet pack/unpack code, and the pin export code
[03:40:34] <jmk-vm02> and link to the existing serial layer code that we will provice
[03:40:38] <jmk-vm02> provide
[03:40:55] <SWPLinux> sure, but it requires a recompile for everyone that wants to use it, until it's included in a new release
[03:40:58] <jmk-vm02> that way, the pins exported by the device can have meaningfull names
[03:41:01] <SWPLinux> yes
[03:41:26] <SWPLinux> you'd need a "prefix" parameter to make more meaningful names
[03:41:30] <SWPLinux> insmod parameter
[03:41:58] <jmk-vm02> worse than that
[03:42:05] <SWPLinux> I wonder if it's possible to have an array of strings insmod parameter
[03:42:11] <jmk-vm02> I think so
[03:42:15] <SWPLinux> interesting
[03:42:28] <jmk-vm02> shudder
[03:42:35] <SWPLinux> not planning thta any time soon
[03:42:40] <SWPLinux> that
[03:44:22] <jmk-vm02> on a completely different topic:
[03:44:26] <jmk-vm02> root@VM02-breezy-nonrt:/mnt/cdrom# ls
[03:44:26] <jmk-vm02> ls: -tools.modules.binary.bld- Input/output error
[03:44:26] <jmk-vm02> 2.objects.vmdesched.o -suse10.1.objects.vmmemctl.o
[03:44:39] <jmk-vm02> that doesn't seem like the vmware tools stuff that I want to install....
[03:45:18] <SWPLinux> hmm
[03:45:58] <SWPLinux> I don't quite understand that paste
[03:46:28] <jmk-vm02> the instructions say to do VM->Install VMware Tools in the vmware console (which I did)
[03:46:36] <jmk-vm02> then go into the guest, and mount the cdrom
[03:46:58] <SWPLinux> yep, then run the install from the CD-ROM
[03:46:58] <jmk-vm02> then untar /mnt/cdrom/vmware-linux-tools.tar.gz
[03:47:06] <jmk-vm02> well, I mounted the cdrom
[03:47:15] <jmk-vm02> and when I ls it, I get the paste above
[03:47:19] <SWPLinux> and you have no .tar.gz file there
[03:47:26] <jmk-vm02> zactly
[03:47:48] <SWPLinux> ok - the I/O error from ls was just a strange thing to me :)
[03:48:21] <jmk-vm02> I was assuming that the VM->Install Tools thing was to tell vmware to connect the "cdrom" containing the tools to the virtual machine
[03:48:28] <SWPLinux> yep
[03:48:50] <jmk-vm02> originally (and still, I think), the cdrom "drive" on the VM was aiming at my breezy iso
[03:49:31] <SWPLinux> that's ok, except that you probably need to unmount the CD within breezy before "installing" the tools CD
[03:49:45] <SWPLinux> then it should be autodetected when it's "inserted"
[03:51:06] <jmk-vm02> that was it
[03:51:15] <jmk-vm02> I had to unmount the breezy iso
[03:51:21] <SWPLinux> ok
[03:51:32] <SWPLinux> there's no lock for the virtual tray ;)
[03:51:54] <jmk-vm02> the guest OS probably got confused when vmware rammed the tools CD into the drive while the breezy "cd" was still there
[03:52:52] <SWPLinux> yep. I bet there was no "media change" notification
[03:53:09] <jmk-vm02> hence the ls error
[03:55:29] <SWPLinux> it's pretty cool once the tools are installed - no more "grab / ungrab" of the pointer, plus you can copy/paste between machines
[03:56:22] <jmkasunich> it also provides higher display resolutions it seems
[03:56:27] <SWPLinux> yep
[03:56:47] <SWPLinux> and probably faster video updates
[03:57:08] <jmkasunich> if I choose a VM res that matches my monitor exactly, that will force full screen operation won't it?
[03:57:15] <SWPLinux> no, it'll scroll around
[03:57:27] <jmkasunich> oh
[03:57:29] <SWPLinux> you can do full screen anyway, though I forget the command for that
[03:57:46] <jepler> there's a toolbar button for it isn't there?
[03:57:49] <jmkasunich> right now the vmware window expands and contracts as the VM changes video modes, etc
[03:57:56] <jmkasunich> yes, I know how to do fullscreen when I want to
[03:58:01] <SWPLinux> yeah, there's a toolbar button, but I'm not sure how to get out of that mode
[03:58:04] <jmkasunich> I just don't wanted to be forced to
[03:58:22] <jmkasunich> heh, good poing
[03:58:23] <jmkasunich> point
[03:58:51] <jmkasunich> I think I'll stick with 1280x1024, even tho my monitor will do 1600x1200
[03:59:10] <SWPLinux> yeah - I ended up doing something similar
[03:59:19] <SWPLinux> 1400x1050, so it would fit in the 1200 vertical
[03:59:38] <SWPLinux> I wonder if there are any widescreen resolutions in the latest VMWare
[04:01:32] <jmk-vm02> test
[04:01:42] <SWPLinux> what?
[04:02:02] <jmk-vm02> the instructions had me restart networking, wanted to see if I was still connected
[04:02:31] <SWPLinux> never got disconnected, in fact
[04:03:39] <jmk-vm02> ok, I think I want to run vmware-toolbox on startup (X startup, not guest boot)
[04:03:57] <SWPLinux> do you not boot the guest into X?
[04:04:00] <SWPLinux> by default
[04:04:06] <jmk-vm02> yes
[04:04:26] <jmk-vm02> well, ubuntu boots into X by default anyway
[04:04:31] <SWPLinux> ah. the toolbox may be superfluous - hold on a sec
[04:06:26] <jmk-vm02> You must restart your X session before any mouse or graphics changes take
[04:06:26] <jmk-vm02> effect.
[04:09:58] <jmk-vm02> I'm going to reboot the guest and see if it starts using tools
[04:13:07] <jmkasunich> well, I got the big video mode at least
[04:13:10] <SWPLinux> cool
[04:13:53] <jmkasunich> boot isn't setting any speed records, but hopefully I won't reboot often
[04:14:23] <SWPLinux> it definitely isn't the fastest thing on earth, especially when the guest is RT-enabled
[04:14:27] <jmkasunich> if I suspend all my vm's before I exit from vmware, does that mean the next time I run vmware I can unsuspend and pick up where I left off on the guest
[04:14:42] <SWPLinux> I'm no tsure I haven't done that
[04:15:02] <jmkasunich> I guessl I
[04:15:06] <SWPLinux> should be, but then again, it would need to save/restore the full memory to/from disk, so it may not save much
[04:15:11] <jmkasunich> I'll have to try it
[04:15:26] <SWPLinux> you're looking at seconds on modern disks, even for a 256M VM
[04:15:48] <jmkasunich> that will beat the heck out of a boot
[04:16:10] <jmkasunich> well, this isn't encouraging
[04:16:13] <SWPLinux> on a non-modern disk, you could be looking at 10 seconds for a 256M VM
[04:16:24] <jmkasunich> I have the ubuntu background, but no icons, no toolbar, etc
[04:16:49] <SWPLinux> you've logged in already?
[04:16:59] <jmkasunich> I got the ubuntu graphical login screen, at 1280x1024, gave my password...
[04:17:19] <SWPLinux> I guess it's just being very slow with the gnome startup
[04:17:32] <jmkasunich> very very slow
[04:17:41] <SWPLinux> hmmm - is the network configured correctly?
[04:17:46] <jmkasunich> no disk activity, and system monitor on the host shows negligable load
[04:18:11] <SWPLinux> click inside the VM - see if that gives it a bit more CPU ??
[04:18:12] <jmkasunich> who the hell knows - installing tools changes the network driver if I read the manual correctly
[04:18:55] <jmkasunich> under normal circumstances this is where I'd hit ctrl-alt-F1 and use a real shell to investigate
[04:19:04] <jmkasunich> don't see how to do that on a VM
[04:19:32] <SWPadnos> yeah - ctrl-alt-anything is problematic
[04:20:43] <jmkasunich> time to reset and use the grub menu - boot a recovery kernel
[04:25:35] <SWPLinux> damn - there's a SourceForge VM you can download
[04:25:41] <jmkasunich> ?
[04:25:43] <SWPLinux> in case you want to run your own SF-like system
[04:26:00] <SWPLinux> http://www.vmware.com/vmtn/appliances/directory/452
[04:26:37] <SWPLinux> that's where VMWare is heading - they want people to distribute apps as VMs, that gets rid of many configuration hassles
[04:26:44] <jmkasunich> well, logging into a "failsafe terminal session" and doing ifup eth0, then exit, then logging into a normal GNOME session got it running
[04:26:50] <jmkasunich> that sucks tho
[04:27:00] <SWPLinux> yeah - shouldn't be necessary
[04:27:18] <jmkasunich> it is nice that I can move the mouse from a VM window to a host window without ctrl-alt
[04:27:32] <SWPLinux> does the eth0 line in /etc/networking/interfaces have "auto" on it?
[04:27:42] <SWPLinux> yep - that's very convenient
[04:28:06] <SWPLinux> I've noticed that the keyboard lights sometimes get weird going from a Win2k VM to the host
[04:28:20] <jmkasunich> no... trying that now
[04:28:21] <SWPLinux> even when num-lock is on in both OSes
[04:30:01] <jmkasunich> damn - I wonder how I change the resolution
[04:30:14] <jmkasunich> I want it smaller - scrolling sucks
[04:30:17] <SWPLinux> did you download vmware workstation or vmware server?
[04:30:21] <jmkasunich> server
[04:30:28] <SWPLinux> ah - I have workstation
[04:30:32] <jmkasunich> workstation isn't free is it?
[04:30:36] <SWPLinux> not after 30 days
[04:30:47] <SWPLinux> but you can set up VMs, and run them with the free player
[04:45:49] <jmk-vm02> finally... boots correctly, network works, running 1200x900
[04:47:59] <jmkasunich> I wonder why I have _two_ processes running "vmware-vmx"
[04:48:23] <jmkasunich> duh, cause I'm running two VMs
[04:52:19] <jmk-vm02> 209 packages to update
[04:52:22] <jmk-vm02> sigh...
[07:32:21] <jmk-vm02> test
[16:11:05] <danfalck> rayh, good morning
[16:27:39] <rayh> Hi Dan. Was on the phone.
[16:27:53] <rayh> Thanks again for the note regarding vista.
[16:28:21] <danfalck> looks like a problem
[16:28:26] <SWPadnos> vista = puke
[16:28:31] <danfalck> for those folks
[16:30:47] <rayh> Hi Steven
[16:31:29] <rayh> I remember all the positive hype about 95 when it came out. How different from vista.
[16:31:36] <SWPadnos> heh
[16:31:56] <SWPadnos> I remember some of the negative hype around '95 :)
[16:32:20] <rayh> Do you.
[16:32:42] <SWPadnos> and from Windows 3.0, 3.1, and even back to Windows 1.xx and 2.xx (which were ugly as sin)
[16:33:12] <skunkworks> I don't remember much positive from any windows release. excpet for microsoft ads.
[16:33:34] <rayh> We were running 3.0, dos, and unix over x back then as a proof that we could.
[16:33:41] <SWPadnos> I think Windows 98 or 98SE were probably the most positively received, except possibly for Win2k
[16:34:08] <SWPadnos> no, 2k was pretty bad until SP3 or SP4
[16:34:47] <rayh> Dan found a post from Art saying mach might never run on vista.
[16:35:13] <rayh> I had my suspicions since they won't even give kernel access to the other security vendors.
[16:35:15] <SWPadnos> heh - getting a certification for his step driver would probably bankrupt him
[16:35:55] <skunkworks> wow - I would have never thought about that kind of problem. Ouch.
[16:36:20] <jepler> "we're the dominant commercial vendor and we're here to f**k you"
[16:36:33] <SWPadnos> they're not that explicit ;)
[16:36:45] <SWPadnos> "we're the dominant commercial vendor, bend over"
[16:36:49] <rayh> In spite of all the nice words they put out about enabling folk.
[16:37:03] <SWPadnos> "enabling people around the world to bend over"
[16:37:12] <rayh> That's it.
[16:37:20] <danfalck> "and you will like it!"
[16:37:20] <SWPadnos> New Windows Flexible Edition
[16:37:48] <rayh> with support for redhat and others.
[16:38:07] <SWPadnos> with support for more bending over, flexibly
[16:45:51] <Lerneaen_Hydra> SWPadnos: wouldn't that be "new windows ulta-stiff, now with extra supple user!"
[16:46:01] <SWPadnos> ewwww
[16:46:01] <SWPadnos> yes
[16:47:44] <skunkworks> new windows vista - ribbed for your pleasure. although windows hasn't really been a 'safe' operating system :)
[16:48:09] <SWPadnos> so anyway, isn't ther esome emc development related topic to discuss? :)
[16:48:35] <danfalck> so we agree that we won't be porting emc to vista right?
[16:48:40] <SWPadnos> aye
[16:48:59] <skunkworks> but mach may be ported to linux?
[16:49:08] <SWPadnos> har har har
[16:49:14] <skunkworks> :)
[16:53:50] <jepler> hmph. just looked at the upgrade manager in dapper (I don't usually use the gui) and it's offering to upgrade me to edgy
[16:53:54] <jepler> should we put another warning on the wiki?
[16:54:15] <SWPadnos> it shouldn't do that unless invoked with the -c command-line option
[16:54:24] <SWPadnos> or some other letter I don't remember
[16:54:28] <jepler> oh really?
[16:54:33] <SWPadnos> yep
[16:54:34] <jepler> this is a fresh install inside vmware
[16:54:38] <SWPadnos> hmmm
[16:55:34] <SWPadnos> yep, it is -c
[16:57:51] <jepler> this is bizarre.
[16:58:30] <jepler> I thought I was installing Dapper 6.06 but the /etc/apt/sources.list has entries that refer to "Ubuntu 6.04 _Dapper Drake_ - Alpha i386 (20060217.2)"
[16:58:40] <SWPadnos> odd
[16:59:06] <SWPadnos> it was originally suppoosed to be 6.04, I wonder if you installed from an RC disc?
[16:59:50] <jepler> I dunno; the filename of the .iso (which I got with bittorrent) doesn't indicate it wasn't the final version
[16:59:51] <SWPadnos> which would make sense for the dist-upgrade option - a release candidate would want to upgrade itself when the final release is done
[17:00:40] <SWPadnos> did you get it from a torrent linked from the ubuntu site?
[17:00:51] <jepler> yes and I've installed it several times
[17:00:55] <SWPadnos> hmm
[17:01:03] <jepler> well I'm not absolutely sure it was this iso image but I think it was
[17:01:06] <SWPadnos> since edgy was released?
[17:01:13] <jepler> no, probably not
[17:04:31] <jepler> hm I have dapper-install-i386.iso (which is 6.04) and ubuntu-6.06-desktop-i386.iso which must be what I used the other times
[17:04:40] <jepler> so I was wrong that I had used this image before
[17:05:03] <SWPadnos> oh, that's a good explanation ofthe result :)
[17:06:13] <jepler> that also explains this "oem" and "server" install option I hadn't remembered seeing before this time
[17:07:57] <jmkasunich> maybe you have a "real" install disk
[17:08:04] <jmkasunich> instead of the "live CD with an install option"
[17:08:16] <SWPadnos> no, there isn't one for ther real 6.06
[17:08:28] <SWPadnos> theres desktop (live), server, or alternate
[17:08:31] <jmkasunich> yeah there is, but its called alternate
[17:08:43] <SWPadnos> but alternate doesn't have a live option, AFAIK
[17:08:52] <jmkasunich> thats a good thing
[17:09:05] <jmkasunich> I have a hunch I'll need to use the alternate to install on a VM
[17:09:17] <jepler> actually what I'm doing is installing to a vm
[17:09:23] <jepler> I did this with ubuntu and kubuntu
[17:09:26] <SWPadnos> you shouldn't need the alternate
[17:09:28] <jmkasunich> my host has only 512M, that means giving a guest much more than 256M is kinda tough
[17:09:31] <jepler> it worked just fine but I give my VMs 512 megs each
[17:09:39] <jmkasunich> and the live doesn't like being crowded
[17:09:48] <jepler> (I have "only" 2GB of physical RAM)
[17:10:00] <jmkasunich> nice
[17:10:22] <jmkasunich> I should probably go get another 512, that isn't very expensive these days
[17:10:29] <jepler> what kind of RAM does that system require?
[17:10:57] <jmkasunich> * jmkasunich tries to remember
[17:11:17] <SWPadnos> athlon XP?
[17:11:23] <jmkasunich> sempron
[17:11:34] <SWPadnos> socket 754 or socket A?
[17:11:53] <jmkasunich> found the mobo manual, I'll have the answer in a sec
[17:11:56] <SWPadnos> DDR400
[17:12:06] <jmkasunich> right
[17:12:07] <SWPadnos> unregistered, unbuffered, ECC supported but not required
[17:12:16] <jmkasunich> PC2100/2700/3200
[17:12:27] <jepler> darn, not old enough to match the spare RAM I think I have laying around
[17:12:41] <jmkasunich> I think I bought 3200, but the CPU I have right now really only needed 2700
[17:12:50] <jmkasunich> I'll get another 3200 though, keep em matched
[17:14:13] <jmkasunich> looks lik $65 at microcenter, probably noticably less on ebay
[17:16:08] <jmkasunich> I did builds of the non-rt EMC2 on this box (dapper, with rt kernel) and on the breezy VM (with stock kernel)
[17:16:25] <jmkasunich> this box: 3:15 real 1:46 user ):22 system
[17:16:36] <jmkasunich> thats 0:22 system
[17:16:55] <jmkasunich> the vm: 5:03 real 2:59 user 1:22 system
[17:17:13] <SWPadnos> was the "host" build done with the VM running?
[17:17:26] <jmkasunich> running but idle
[17:17:29] <SWPadnos> ok
[17:17:38] <jmkasunich> pretty negligable system load at the time
[17:17:44] <SWPadnos> well, idle as in nothing being run on the gues t OS< but the guest was "powered up"?
[17:17:51] <jmkasunich> yeah
[17:17:53] <SWPadnos> ok
[17:17:57] <SWPadnos> and both after a make clean
[17:17:59] <SWPadnos> ?
[17:18:14] <jmkasunich> yep
[17:18:29] <SWPadnos> i'd be curious to see the time for a make -j 3 or -j 2
[17:18:42] <jmkasunich> did it twice, picked up a few seconds (only) the second time, so disk caching didn't help much
[17:18:54] <jmkasunich> did a -j2 it only saved a few more seconds
[17:18:58] <SWPadnos> ok
[17:18:59] <jmkasunich> (on the vm)
[17:19:11] <jmkasunich> didn't try -j on this box, gonna do a few more runs now
[17:19:20] <SWPadnos> I found that having a large terminal window to scroll around actually added several seconds
[17:19:40] <SWPadnos> and that's with a fast video card
[17:20:12] <jmkasunich> several seconds on 3 or 5 mins isn't much
[17:20:18] <jmkasunich> makes more of a difference on your box
[17:20:19] <SWPadnos> on 20 seconds it is
[17:20:22] <SWPadnos> yep
[17:20:47] <SWPadnos> what video driver are you using - the difference may be more significant on your machine
[17:21:06] <jmkasunich> on the vm, or the host?
[17:21:10] <SWPadnos> I'm not sure that the nvidia driver uses the card for text scrolling, but I'd hope it would
[17:21:12] <jepler> adding all those conversion comps added so much time to the compile
[17:21:11] <SWPadnos> the host
[17:21:14] <jepler> I wonder if those are a good idea or not
[17:21:25] <SWPadnos> I think some of them are, but maybe not all of them
[17:21:44] <SWPadnos> since you can chain them if necessary
[17:21:58] <jmkasunich> ok, with no vm running at all (console off and all vm's powered off, server still going) I got:
[17:22:08] <jmkasunich> real 2m13.018s
[17:22:09] <jmkasunich> user 1m36.242s
[17:22:09] <jmkasunich> sys 0m14.211s
[17:22:12] <jepler> I considered that too. Perhaps s32 and u32 are the only ones that should have a full range of converters to and from
[17:22:36] <jmkasunich> float to <someint> will be needed at times I bet
[17:22:43] <jmkasunich> but that one should have scale and offset params
[17:22:53] <SWPadnos> yeah, and the converter between the two should convert between sign/magnitude and int
[17:23:09] <jmkasunich> I want to strongly discourage the use of the shorter int types
[17:23:13] <SWPadnos> between signed and unsigned, I was talking about
[17:23:18] <jmkasunich> ok
[17:23:32] <SWPadnos> does anything use the S/U16?
[17:23:36] <jepler> s16/u16 seem particularly purposeless
[17:23:46] <jmkasunich> in hindsight, I think the pile of int types was a mistake, and would like to eventually remove them
[17:24:31] <jmkasunich> have an "analog" type, a "quantized" type (sint, and/or uint) and a "boolean" type only
[17:24:52] <SWPadnos> it may make sense to have them, but only if you ever want to e able to do hardware-specific things in a HAL config context, vs. a HAL driver context
[17:24:59] <SWPadnos> s/e/be/
[17:27:03] <jepler> but what if your hardware has 24 bits?
[17:27:25] <SWPLinux> you extend to 32, like the USC driver
[17:27:43] <jmkasunich> thats why I want to use 32 for everything at the actual HAL level, and let the driver do the rest
[17:29:26] <SWPLinux> the 5i20 driver references both u16 and s16 types
[17:30:29] <jmkasunich> with -j 2:
[17:30:30] <jmkasunich> real 2m7.447s
[17:30:30] <jmkasunich> user 1m36.826s
[17:30:30] <jmkasunich> sys 0m13.986s
[17:30:41] <SWPLinux> actually, the S16 isn't exported, it's used internally to one function
[17:30:51] <jmkasunich> saved a whopping 7 seconds
[17:30:56] <SWPLinux> woohoo!
[17:34:04] <jmkasunich> I bet your box is disk limited, and mine is CPU limited
[17:34:31] <SWPLinux> that may be so, but the time doesn't change much with successive runs, and I have 4G in this machine
[17:34:51] <jmkasunich> well then its the dual cores
[17:35:13] <SWPLinux> the files should all fit in cache, though I'm not sure what happens after make clean
[17:35:14] <jmkasunich> how does -j <numcores> compare to -j <numcores*2> ?
[17:35:28] <SWPLinux> dunno - one sec
[17:36:38] <SWPLinux> -j 4 seems to keep the CPUs pegged, similar to "-j"
[17:37:25] <SWPLinux> real 0m31.919s
[17:37:25] <SWPLinux> user 1m24.349s
[17:37:26] <SWPLinux> sys 0m19.181s
[17:37:43] <SWPLinux> so I guess it doesn't, even though the system monitor looks that way
[17:38:52] <SWPLinux> -j 8:
[17:38:52] <SWPLinux> real 0m29.780s
[17:38:55] <SWPLinux> user 1m24.945s
[17:38:55] <SWPLinux> sys 0m19.489s
[17:39:28] <jmkasunich> not much savings there
[17:40:00] <SWPLinux> no - I have more stuff running now than before, so the time is ~30 seconds instead of ~20
[17:40:10] <SWPLinux> -j:
[17:40:12] <SWPLinux> real 0m30.253s
[17:40:13] <SWPLinux> user 1m25.025s
[17:40:13] <SWPLinux> sys 0m19.069s
[17:40:24] <jmkasunich> I think -j <more than numcores> only makes sense when the disks are so slow that cores wind up waiting for stuff to compile
[17:40:40] <SWPLinux> the recommendation is 2x numcores
[17:40:55] <SWPLinux> so one compile is waiting for disk transfer while another is working
[17:41:07] <SWPLinux> otherwise the compile and disk are serialized
[17:41:19] <jmkasunich> yeah, but that doesn't seem to make a significant difference in your testing or mine
[17:41:32] <SWPLinux> that's true
[17:41:34] <jmkasunich> _maybe_ 5%
[17:41:52] <SWPLinux> I wonder if it's more important for small files or large ones ...
[17:42:04] <SWPLinux> I guess small ones
[17:42:43] <SWPLinux> well, files where the time to read/write is similar to the time to compile
[17:43:04] <SWPLinux> hmmm - I wonder if the added compile time is due to all the conv* components?
[17:43:15] <jmkasunich> as you said, your system has enough ram to cache pretty much all the files
[17:43:31] <SWPLinux> yep - after teh make it shows 52% in use as cache
[17:43:36] <jmkasunich> make clean deletes the objs and bins of course, but I bet the source files aren't being read from disk
[17:44:33] <jmkasunich> the writes are buffered by linux anyway, so I would expect all but the very first build to be CPU bound
[17:46:07] <SWPLinux> yep
[17:47:26] <SWPLinux> you know - there is one other type that could be useful - a "fraction"
[17:47:45] <SWPLinux> quantized values, analog values, bits, and fractions
[17:47:56] <jmkasunich> fractions?
[17:48:07] <SWPLinux> ie, fixed point values, using 32-bit numbers
[17:48:19] <SWPLinux> not pairs of ints used as numerator/denominator ;)
[17:48:48] <SWPLinux> drivers would know that they need to take the high N bits (whatever N is significant to the hardware)
[17:48:50] <jmkasunich> why?
[17:49:12] <SWPLinux> it gives an automatic conversion by taking the high N bits
[17:49:28] <jmkasunich> any quantiized value can be used as a fixed point number - the two endpoints just need to agree on the location of the point
[17:49:31] <SWPLinux> there's no change to the value, only the precision
[17:50:07] <SWPLinux> sure - but there's implicit agreement if you have a 32-bit fixed point fraction type
[17:50:26] <jmkasunich> seems like you have 32 fixed point types
[17:50:30] <SWPLinux> so you don't need parameters or hard-coded precision values
[17:50:34] <SWPLinux> no - just one
[17:50:39] <jmkasunich> one with the point at bit 31, one at 30, etc
[17:51:02] <SWPLinux> no, that's why I called it a fraction
[17:51:07] <jmkasunich> oh, do you mean a signed int that is interpreted as ranging from -1.0 to 1.0?
[17:51:12] <SWPLinux> yes
[17:51:27] <SWPLinux> top bit is sign, next 31 are fraction
[17:51:36] <jmkasunich> and why not use a float for that kind of thing?
[17:51:39] <SWPLinux> if youhave 8-bit hardware, you use 31..25
[17:52:06] <SWPLinux> well, you need FP functions for that, and you can end up with quantization error
[17:52:26] <SWPLinux> you can use nofp on a fraction
[17:52:33] <jmkasunich> thats true
[17:52:45] <jmkasunich> and you get true 32 bit resolution, instead of 24 bit
[17:52:56] <SWPLinux> yep (31 with sign, but yes)
[17:53:13] <jmkasunich> I'd like to figure out how to use doubles for the analog signals
[17:53:20] <SWPLinux> and it's obvious that you just lop off the unused bits when you don't have hardware that uses them
[17:53:19] <jmkasunich> then you get 56 bit resolution
[17:53:56] <SWPLinux> yes, and there's another problem when you start thinking about thread safety
[17:54:15] <jmkasunich> the _only_ problem with doubles is thread safety
[17:54:44] <SWPLinux> well, there's another problem in general, because sometimes multiple signals really are part of the same thing
[17:55:09] <SWPLinux> so each signal is atomically updated, but a set of signals isn't
[17:55:26] <jmkasunich> thats pretty uncommon though
[17:55:45] <jmkasunich> the premise of HAL is that signals passing between threads are asynchronous
[17:55:58] <SWPLinux> well, the recent discussion about tool selection would be a case in point, if the person were using a parport for the tool select bits
[17:56:04] <SWPLinux> and using software step generation
[17:56:13] <jmkasunich> so if you have several signals that all need to change at exactly the same time, you are probably doing something that isn't well suited to the HAL archectiture
[17:56:31] <SWPLinux> like updating several output bits that go to a toolchanger?
[17:56:51] <jmkasunich> you are sending a binary word to the toolchanger?
[17:57:24] <jmkasunich> usually, you are controlling the changer
[17:57:26] <SWPLinux> yes, via parport bits or bit outputs on a 5i20 (since that's the only way to get multiple bits of output in HAL)
[17:57:40] <jmkasunich> you might be getting a binary word back from it (a set of prox sensors for example)
[17:57:57] <jmkasunich> but that word is pretty much guaranteed to be asynchronous
[17:58:11] <SWPLinux> yep, and those may also change in interesting ways between reads (assuming that individual functions are interruptible)
[17:58:15] <jmkasunich> different sensors will change state at different times as the turret turns
[17:58:27] <SWPLinux> sure - it's a debounce problem
[17:58:44] <jmkasunich> thats why there is usually a "in position" sensor, and you ignore all the others until it goes true
[17:58:49] <SWPLinux> yes
[17:59:33] <SWPLinux> look at Eric Johnsons thing though - he needs one-of-N bits to be on to select the correct tool
[17:59:42] <SWPLinux> there's no way to set those bits at the same time
[17:59:52] <jmkasunich> sending a binary word _to_ something outside (like a toolchanger controller) is also a debounce issue
[17:59:53] <SWPLinux> (though the glitch duration will likely be small)
[18:00:11] <SWPLinux> yes, you need a clock line (like in-position)
[18:00:17] <SWPLinux> data_valid
[18:00:26] <jmkasunich> which we have for toolchangers
[18:00:38] <jmkasunich> tool number comes out, then tool-change-request goes true
[18:01:02] <SWPLinux> is there a delay between the two?
[18:01:10] <jmkasunich> to be honest, I'm not sure
[18:01:19] <jmkasunich> thats in iocontrol
[18:01:35] <jmkasunich> * jmkasunich looks
[18:01:48] <SWPLinux> well, consider the int-to-bit_array thing I'm doing
[18:02:13] <SWPLinux> from iocontrol, the "tool-change-request" goes straight to the parport
[18:02:33] <SWPLinux> the tool bnumber goes into something that converts a number into a bunch of bits, each of which are then routed to parport
[18:02:38] <SWPLinux> number
[18:03:51] <jmkasunich> looks like there is no intentional delay between the tool number and the tool-prepare signal
[18:04:28] <jmkasunich> * output, pin that holds the tool number to be prepared, only valid when tool-prepare=TRUE */
[18:04:44] <jmkasunich> the code clearly acknowleges that the number can be invalid at times
[18:05:35] <jmkasunich> anything operating on an electromagnetic time scale (relays, motors, solenoids, etc) won't see the glitches
[18:05:37] <jepler> so this new component would have to delay the tool-prepare signal while its other outputs might be unstable, or else have its own 'valid' output which would be AND'd with tool-prepare
[18:06:13] <SWPLinux> argh - phone
[18:06:43] <jmkasunich> actually, just sending the signal thru a gate (like and AND) would be sufficient, even if the other input of the gate is tied true
[18:06:53] <SWPLinux> since all the outputs for a given piece of hardware get updated essentially simultaneously, it probably isn't much of a problem
[18:06:56] <jmkasunich> just put the gate after the bit-splitter in the thread
[18:07:23] <jmkasunich> there are two levels (that I can think of) of glitches
[18:07:52] <jmkasunich> 1) bits split between outb() instructions in the same driver (for instance, the data and control ports of a parport)
[18:08:10] <jmkasunich> pins 2-9 get written at the same time, but pins 14, 15, etc are a uS or so later
[18:08:44] <jmkasunich> 2) (maybe 1a) bits split between two drivers (for example, if you send some bits out the parport, and others out a m5i20
[18:08:57] <jmkasunich> maybe 1 and 2 are the same thing - a few uS in any case
[18:09:11] <jmkasunich> 3) things that get skewed by a full thread time
[18:09:24] <SWPLinux> three, yes three levels! ;)
[18:09:35] <jmkasunich> could be 20uS, 50uS, or a millisecond, depending on the threads you are using
[18:09:57] <SWPLinux> side note: has anyone tried doing a word write to the parport instead of two outb?
[18:10:11] <jmkasunich> in the toolchange case, iocontrol writes a single number and the prepare signal
[18:10:14] <jepler> there's no rtapi_outw so clearly it's not possible :-P
[18:10:16] <SWPLinux> heh
[18:10:39] <SWPLinux> mov ah, ctl; mov al, data; outw dx,ax
[18:10:43] <jmkasunich> arch
[18:10:47] <jmkasunich> argh
[18:10:54] <jmkasunich> stop changing the subject
[18:11:06] <SWPLinux> or just out dx,ax - it's been a while :)
[18:11:08] <SWPLinux> sorry
[18:11:21] <jmkasunich> iocontrol writes to a tool number and to the prepare bit
[18:11:49] <jmkasunich> it should write to the toolnumber first, so if the RT code runs between the two writes the number is valid before the bit goes true
[18:11:53] <jmkasunich> (checking now)
[18:12:00] <SWPLinux> yes, and the number will very likely need to be split into bits to get out to the world
[18:12:24] <jmkasunich> but that part takes place in a RT thread
[18:12:36] <SWPLinux> which means that at some point in HAL, there's a group of signals that are part of the same "value", and aren't atomic
[18:13:06] <jmkasunich> I guess if the splitter is in one thread (servo) and the output is in another (base), then you have a risk
[18:13:13] <jmkasunich> if splitter and output are in the same thread, no problem
[18:13:22] <SWPLinux> I think the potential problems caused by that can be mostly solved by careful thread function ordering and the like
[18:14:12] <SWPLinux> I'm thinking forward to when nearly every computer sold will be multi-core, and having to use a UP kernel will be a problem (or at least an annoyance)
[18:14:41] <SWPLinux> at that point, thread safety and "glithces" become more important
[18:14:47] <SWPLinux> glitches
[18:14:52] <SWPLinux> see - there's one now ;)
[18:15:00] <jmkasunich> rtapi places all RT tasks on the same CPU
[18:15:15] <jmkasunich> kind of a head-in-the-sand approach, but it helps a little
[18:15:29] <SWPLinux> how does it do that, when it doesn't work on SMP systems?
[18:15:36] <jmkasunich> the other cpu(s) can be used to run user space stuff
[18:15:46] <SWPLinux> sure - that's a perfectly viable approach
[18:16:18] <SWPLinux> any multi-core CPU will have plenty of power for EMC on one of the cores
[18:16:18] <jmkasunich> rtai has support for "create thread on cpu()" and rtapi always calls that function, passing cpu number 0
[18:16:26] <SWPLinux> ah - ok
[18:16:35] <SWPLinux> so assuming we can get a working smp/A64 RTAI, things could "just work"
[18:16:46] <jmkasunich> they should
[18:16:59] <jmkasunich> the rtai folks have made smp kernels
[18:17:13] <jmkasunich> its just that we haven't gone to the trouble of building one or distributing it
[18:17:46] <SWPLinux> multicore / SMP was what got me thinking about these kinds of synchronization issues - just reading a bit several times (like the mux4 component does) is a potential glitch waiting to happen
[18:17:57] <jmkasunich> oops
[18:18:02] <jmkasunich> I try not to do that
[18:18:20] <jmkasunich> mostly I write a component to access a hal pin or param only once
[18:18:25] <SWPLinux> yep. the new comp version does that, which is what got me started on that thought path
[18:18:33] <SWPLinux> yep - the PLC approach
[18:18:46] <SWPLinux> read all / do stuff / write all
[18:21:34] <SWPLinux> actually - mux4 only reads each input once (there are two paths for the read of sel1), but there's another example where the two selector inputs are actually part of a single quantity
[18:22:23] <SWPLinux> and that can cause a type 3 glitch if the inputs are changed in a fast thread while mux4 is running in a slow thread
[18:23:00] <jmkasunich> they're not always coming _from_ a single quantity, even if they are eventually used as a such
[18:23:29] <jmkasunich> in the mazak spindle control, I'm pretty sure I use a mux4, with the two sel bits coming from completely different places
[18:23:50] <SWPLinux> sure, but my point was that there are two atomically updated things that together aren't atomic, but they're interpreted as a single entity
[18:24:47] <jmkasunich> granted... but I don't think that warrents the additional complexity that is implied by atomic groups
[18:24:47] <jmkasunich> linksp sp-mtr-high-rpm-cmd mux4.0.in0
[18:24:48] <jmkasunich> linksp sp-mtr-low-rpm-cmd mux4.0.in1
[18:24:48] <jmkasunich> linksp sp-mtr-mesh-rpm-cmd mux4.0.in2
[18:24:48] <jmkasunich> linksp sp-mtr-mesh-rpm-cmd mux4.0.in3
[18:24:48] <jmkasunich> linksp sp-in-low-gear mux4.0.sel0
[18:24:48] <jmkasunich> linksp sp-shifting mux4.0.sel1
[18:25:15] <SWPLinux> atomic groups are the same complexity as atomic doubles, I think
[18:25:28] <jmkasunich> in this case, the two sel bits come from completely differnt places and change state at different times
[18:25:47] <jmkasunich> I disagree about doubles vs. groups
[18:25:53] <SWPLinux> the easiest way to have them is to disallow RW pins, so there is at most one writer to a "big" signal
[18:26:07] <jmkasunich> huh?
[18:26:19] <SWPLinux> at a low level, they're the same - they both require multiple CPU instructions to update a "single" quantity
[18:26:28] <jmkasunich> multiple writers are a _completely_ different issue
[18:26:35] <jmkasunich> (but one that may make things worse)
[18:26:57] <SWPLinux> I'm simplifying the multi-cycle object case by disallowing multiple writers
[18:27:16] <SWPLinux> the buffer-flipping thing we discussed 2 years ago would work for a single-writer case
[18:27:23] <jmkasunich> you can easily have non-atomic results with a single writer, if the item (group of items) being written is half written when another thread reads it
[18:27:35] <SWPLinux> it's much more difficult with multiple writers, I think
[18:27:52] <jmkasunich> perhaps
[18:28:00] <jmkasunich> but you are looking only at the internals
[18:28:12] <SWPLinux> yes - the issue even with a single writer is knowing if a copy is "in use" by another thread
[18:28:21] <SWPLinux> err - function
[18:28:41] <SWPLinux> ?
[18:28:42] <jmkasunich> the reason I say groups are more complex than doubles is external - how do you specify what is in a group? how do you keep track of groups? that is the extra complexity
[18:28:54] <SWPLinux> oh sure - that's a whole other world
[18:29:32] <SWPLinux> but the infrastructure is the same - once we can figure out how to make "big things" effectively atomic, the infrastructure is there for grouped signals as well
[18:29:51] <SWPLinux> (like an "encoder", instead of counts, position, offset, error, index ...)
[18:30:02] <jmkasunich> the infrastructure for grouped signals is far far more complex
[18:30:24] <Lerneaen_Hydra_> Lerneaen_Hydra_ is now known as Lerneaen_Hydra
[18:30:33] <SWPLinux> that's very true for arbitrary groups defined in a hAHAL file, but not necessarily for well-defined groups, such as canonical interfaces
[18:30:45] <jmkasunich> the "big things" you are talking about aren't even contiguous in memory
[18:31:11] <jmkasunich> you can't do buffer flipping, because ther is no single pointer that points to all the members of a group
[18:31:12] <SWPLinux> it makes no difference - if you can protect two CPU cycles then you can protect 200 CPU cycles
[18:31:20] <jmkasunich> unless you want to add _two_ levels of indirection
[18:31:46] <jmkasunich> I'm not thinking in terms of protecting _any_ cpu cycles
[18:32:17] <SWPLinux> well, writing a double takes two instructions (unless you use the FPU, maybe)
[18:32:19] <jmkasunich> with an atomic write to a single location, if you read it before a certain clock cycle, you get the old value, if you read it after you get the new value
[18:32:35] <jmkasunich> you never have to disable or defer reading at all, there is NO time period that you are "protecting":
[18:33:08] <jmkasunich> the double buffering scheme gets around that by making the critical write the one to the pointer, not to the double itself
[18:33:15] <SWPLinux> sure
[18:33:32] <jmkasunich> I admit I didn
[18:33:34] <jmkasunich> oops
[18:33:41] <jmkasunich> I didn't realize the multiple-writer problem
[18:33:47] <SWPLinux> I was looking at is as the double buffer protecting the multiple writes needed to save one double
[18:33:57] <jmkasunich> exactly
[18:34:18] <jmkasunich> and if there is only one writer to that signal, that is adaquate
[18:34:34] <SWPLinux> well, almost adewuate ;)
[18:34:37] <jmkasunich> if there are two writers, _and_ they are in differnet threads, then the double buffer isn't enough
[18:34:39] <SWPLinux> adequate
[18:34:55] <jmkasunich> almost?
[18:35:27] <SWPLinux> there's still a problem if a reader has read one 32-bit quantity, and the buffer gets flipped before the second read
[18:36:07] <jmkasunich> I don't think so
[18:36:20] <jmkasunich> gotta run the thought experiment tho
[18:36:25] <SWPLinux> yeah - the writer thread would have to run twice between successive reads
[18:36:38] <jmkasunich> 1) writer writes to the idle buffer
[18:36:47] <jmkasunich> 2) writer flips ptr from active buffer to idle buffer
[18:37:00] <jmkasunich> 3) reader reads ptr
[18:37:11] <jmkasunich> 4) reader reads active buffer using local copy of ptr
[18:37:40] <jmkasunich> even if 3 happens between 1 and 2, the reader is ok
[18:37:58] <jmkasunich> it would have to go 1, 3, 2, 1, 4 to break it
[18:38:03] <SWPLinux> yes - between 3 and 4, the writer would have to run twice to screw up a read
[18:38:13] <SWPLinux> you know - there's another easy way I've used on microcontrollers
[18:38:35] <SWPLinux> it's a bit icky, but it "just works" when you know the CPU speed is high compared to the thread execution rate
[18:38:45] <SWPLinux> one sec - phone
[18:39:06] <jmkasunich> read until you get two in a row that are the same?
[18:39:09] <SWPLinux> yep
[18:39:25] <SWPLinux> or read twice, and if they're different, use the iold value
[18:39:46] <jmkasunich> old = from the previous cycle? or the first read?
[18:39:53] <SWPLinux> at least that's time bounded
[18:40:03] <SWPLinux> old = previous cycle
[18:40:29] <jmkasunich> that requires additional storage that persists from cycle to cycle - I'd rather avoid that
[18:40:47] <SWPLinux> new1 = read(); new2=read(); if new1==new2, val=new1 else val=oldval
[18:41:09] <jmkasunich> given the speed of modern CPUs, especially since the reads are from cache, I'd rather do:
[18:42:06] <jmkasunich> new1=read(); new2 = read(); while ( new1 != new2 ) { new1 = new2; new2 = read(); }
[18:42:59] <jmkasunich> the only way that gets unbounded is if by some freaking miracle you manage to interrupt it between the two reads repeatedly
[18:43:25] <SWPLinux> hey - I've gotta run - my wife just called from a nearby resdtaurant asking if I want to join her :)
[18:43:32] <jmkasunich> which basicaly means that there is zero time left to run the interrupted thread anyway
[18:43:35] <jmkasunich> ok, enjoy lunch
[18:43:38] <SWPLinux> yeah - it generally takes at most 3 reads to get a stanle value
[18:43:40] <SWPLinux> stable
[18:43:58] <SWPLinux> I'll be back later though
[18:43:59] <jmkasunich> ok
[18:45:23] <jmkasunich> heh, lunchtime here too - my wife just got home from church
[20:28:05] <A-L-P-H-A> jmkasunich: are you a republican as well??
[20:28:32] <SWPLinux> them's fightin' words in some parts
[20:30:24] <A-L-P-H-A> not unless he is a stink'n republican.
[20:30:52] <SWPLinux> well, no. if he's not a stinking republican, and you ask that question, then it's a fightin' thing
[20:30:53] <A-L-P-H-A> I have a friend, that's last name is O'Lerry [or something like that]
[20:31:25] <A-L-P-H-A> I asked him once, "That's Irish right? I mean no offense if it isn't"
[20:31:27] <A-L-P-H-A> foot in mouth. hahahahhaa
[20:31:54] <SWPLinux> heh
[20:32:02] <A-L-P-H-A> I felt so stupid afterwards, he just laughed at me, cause he know I didn't mean anything, it was just a question, but the "No offense" afterwards...
[20:32:12] <SWPLinux> have you seen the TV show "The Office"?
[20:32:35] <A-L-P-H-A> there was a slight pause... cause he's a slow talker... so I wasn't sure if I offended him.
[20:32:45] <A-L-P-H-A> slow talkers drive me nuts...
[20:32:51] <SWPLinux> y
[20:32:55] <SWPLinux> e
[20:32:57] <SWPLinux> s
[20:32:57] <A-L-P-H-A> makes me think that they are mentally slow as well.
[20:32:58] <A-L-P-H-A> shut up
[20:33:01] <SWPLinux> heh
[20:33:31] <A-L-P-H-A> he types fast enough... just that when I speak with him... makes you all annoyed.
[20:33:48] <A-L-P-H-A> Torontonians actually talk fast... kind weird... as I don't notice it...
[20:34:01] <A-L-P-H-A> when you walk into a small town... yikes... slow talkers everywhere.
[20:34:18] <SWPLinux> sometimes true. city folk tend to be a bit more in a hurry
[20:34:52] <A-L-P-H-A> I don't know many cities that are faster than Toronto... speaking wise...
[20:35:03] <A-L-P-H-A> maybe HK, Tokyo...
[20:35:22] <SWPLinux> yeah, Beijing or Mexico City as well ;)
[20:35:27] <A-L-P-H-A> NYC is about the same, but we enunciate our words better.
[20:35:47] <SWPLinux> New Yawkers enunciate well, but wrong
[20:35:57] <A-L-P-H-A> none of this Bronxs crap.
[20:36:54] <A-L-P-H-A> wonder does a slower lifestyle allow for a longer life... with the same amount of stress that is.
[20:37:08] <SWPLinux> dunno
[20:46:44] <jmkasunich> argh... the Browns suck
[20:47:08] <SWPLinux> that's a sports team from Cleveland, right?
[20:47:17] <SWPLinux> what - football?
[20:47:25] <jmkasunich> yeah
[20:47:42] <jmkasunich> I don't normally watch, but today I started
[20:47:49] <jmkasunich> and then got disgusted
[20:47:54] <jmkasunich> they actually started out 14-0
[20:48:07] <jmkasunich> but things went to hell in the 2nd half
[20:48:23] <SWPLinux> heh
[20:48:47] <jmkasunich> the other team was 4th and 1 on about the cleveland 30, and they went for it
[20:49:01] <jmkasunich> a Cleveland defender intercepted at the 1 yard line
[20:49:23] <jmkasunich> idiot - if he'd have knocked it down we'd have the ball at the 30, instead they got it at the 1
[20:49:29] <SWPLinux> I kind of stopped following football back in the PIttsburgh Steelers/Dallas Cowboys heyday, maybe the early '80s :)
[20:49:59] <jmkasunich> I lived in western PA back then.... I remember the Steelers in their prime
[20:50:15] <jmkasunich> one for the thumb and all that
[20:50:34] <SWPLinux> a lot of the greats played back then - Rosy Greer, Lynn Swann, Fran Tarkenton ...
[20:53:01] <jmkasunich> ok, where were we....
[20:53:16] <SWPLinux> multiple reads to get consistent readings
[20:53:22] <jmkasunich> yeah
[20:53:35] <SWPLinux> which is fine for doubles, but not for "clusters"
[20:53:47] <SWPLinux> (only pointing that out, not complaining)
[20:53:46] <jmkasunich> crap - I turned on the radio to keep an ear on the game... and its even worse now
[20:53:53] <SWPLinux> heh
[20:55:19] <jmkasunich> this whole thing started with the surplus integral types
[20:55:32] <SWPLinux> yep, sort of
[20:55:45] <jmkasunich> then fractional types
[20:55:56] <jmkasunich> then doubles, and finally atomic groups
[20:56:02] <SWPLinux> I'm writing an int to multiple-bits converter, and that causes non-atomic updates of groups (the output bits)
[20:56:02] <jmkasunich> so... what should be done, and when
[20:56:25] <SWPLinux> well, the whole double thing will take a bit of testing, so I'd certainly defer that
[20:56:42] <jmkasunich> its very tempting to get rid of the 8 and 16 bit integer types for 2.1
[20:56:55] <SWPLinux> groups or clusters of HAL pins are definitely something to not mess with any time soon
[20:57:04] <SWPLinux> I don't think I'd do that now - they don't hurt anything
[20:57:25] <jmkasunich> but if they go away, we prevent anybody from using them
[20:57:33] <jmkasunich> and thus spare them pain later
[20:57:59] <SWPLinux> I do think that the number of converters should be reduced though - make a series of larger -> smaller converters and smaller->larger, then chain them if you want to go multiple steps in either direction
[20:58:05] <jmkasunich> the float to double change will be transparent to users, we'll continue to call the "analog" signals float
[20:58:14] <jmkasunich> they'll just be more precise
[20:58:15] <SWPLinux> well, there are places where the midsize types are used internal to drivers
[20:58:40] <jmkasunich> if they are internal to drivers, they shouldn't neccessarily be using the hal types
[20:58:45] <SWPLinux> sure, but all floats will have to be changed to doubles, and some benchmarking should be done before committing that as a systemwide change
[20:58:55] <SWPLinux> I agree on the driver thing
[20:59:09] <jmkasunich> right - I'm not proposing the float->double thing for 2.1... I want to do that for 2.2 though
[20:59:34] <jmkasunich> we have a couple of conversations interleaved
[20:59:53] <SWPLinux> yep - sorry
[21:00:04] <SWPLinux> let's start with the mid-size types
[21:00:04] <jmkasunich> the "transparent" part for floats - what I mean is that hal files won't need changed
[21:00:10] <jmkasunich> ok
[21:00:34] <SWPLinux> using grep/wc, there are 12 files that reference hal_u16, hal_s16, and hal_s8
[21:00:41] <SWPLinux> there are 14 that reference hal_u8
[21:00:57] <jepler> if store/load double is not atomic, I don't see how you make the change transparent at the source-code level.
[21:01:06] <SWPLinux> some are headers, so they don't count
[21:01:13] <jmkasunich> you don't - I was strictly thinking user level
[21:01:19] <SWPLinux> right - that's the the issue I was seeing with it
[21:01:24] <jmkasunich> although maybe .comp files could be transparent
[21:01:29] <jepler> some of the 8, 16 sizes are in halmodule, discount those too
[21:01:45] <jmkasunich> some are the conv components
[21:01:46] <SWPLinux> true, and sampler/streamer
[21:01:50] <jmkasunich> some are in halcmd, halscope, etc
[21:02:08] <SWPLinux> I guess ppmc and 5i20 are the main ones I noticed
[21:02:12] <jmkasunich> to be honest, there is a _lot_ of code that would get simpler
[21:02:43] <SWPLinux> freqgen uses u8's as step timing parameters
[21:02:47] <SWPLinux> and stepgen
[21:02:51] <jmkasunich> hmm
[21:03:03] <jmkasunich> those could certainly be ints
[21:03:26] <SWPLinux> oops - hold on, I was doing that in the components dir, not the hal/ dir
[21:03:35] <jmkasunich> sane values for those are probably less than 10 or 20, its not like 8 bits is being used to filter insane values
[21:03:54] <jepler> http://pastebin.ca/246907
[21:04:04] <SWPLinux> right - it just seems more efficient to use 8 bits for such a small number
[21:04:30] <jmkasunich> for params that is true
[21:04:37] <jmkasunich> for pins, not really
[21:04:43] <jmkasunich> since the actual pin is a pointer, not a value
[21:04:59] <SWPLinux> it's not really true for params either - it's only a small space savings
[21:05:04] <SWPLinux> not a time savings
[21:05:14] <jmkasunich> right, time might actually be worse
[21:05:22] <SWPLinux> yep
[21:05:22] <jmkasunich> I also have to wonder about atomicity
[21:05:49] <jmkasunich> if you change a single byte, does the system do a 32 bit read/modify/write? or can it write single bytes
[21:05:54] <jepler> x86 can and probably does
[21:05:55] <SWPLinux> if a nultibyte value is not dword-aligned, then there may be both time and atomicity issues
[21:06:06] <SWPLinux> multibyte
[21:06:12] <jmkasunich> gcc alignes multibyte variables
[21:06:42] <jmkasunich> if you have a struct that contains some bytes, and some ints, there is empty space after the bytes if needed, so the ints are aligned
[21:06:47] <jmkasunich> (assuming the struct is aligned)
[21:07:02] <SWPLinux> I think we determined that structs are packed, but I guess a word value will always be on a 2-byte boundary (unless you explicitly ask for struct packing, which should not add any padding)
[21:07:02] <jmkasunich> hal_shmalloc() returns 4-byte aligned addresses
[21:08:01] <jmkasunich> when you say word value, do you mean 16 bit? ;-)
[21:08:14] <jmkasunich> ints are 4 byte aligned, shorts are 2 byte aligned
[21:08:30] <jmkasunich> unless you are using a 64 bit platform
[21:09:09] <jmkasunich> we really need consistency in fixed length types, I just know there are places where 64 bits is gonna bite us in the rear
[21:09:23] <SWPLinux> yeah - on x86, a byte is 8 bits, word is 16, dword is 32 ...
[21:09:36] <SWPLinux> 64 is aqword
[21:09:39] <SWPLinux> a qword
[21:09:45] <A-L-P-H-A> k
[21:09:47] <A-L-P-H-A> I was about to ask
[21:09:53] <A-L-P-H-A> but you answered... qword
[21:10:02] <SWPLinux> and the 80-bit floats are tenbytes :)
[21:10:03] <A-L-P-H-A> what's 128bits then?
[21:10:12] <SWPLinux> those are SIMD registers
[21:10:19] <jmkasunich> thing is, I tend to think of "word" as being the native size
[21:10:20] <A-L-P-H-A> 256
[21:10:22] <A-L-P-H-A> 512
[21:10:25] <A-L-P-H-A> 1024
[21:10:26] <jmkasunich> which is no longer 16
[21:10:27] <A-L-P-H-A> 2048?
[21:10:34] <A-L-P-H-A> 4096
[21:10:47] <jmkasunich> irrelevant anyway...
[21:10:50] <A-L-P-H-A> 8192?
[21:11:11] <jmkasunich> we need fixed size typdefs to be use for HAL and only HAL stuff (pins and params)
[21:11:20] <A-L-P-H-A> I think I chipped a filling.
[21:11:27] <A-L-P-H-A> or a tooth...
[21:11:29] <jmkasunich> and we also need fixed size typdefs to be use elsewhere when a fixed size is needed
[21:11:45] <jmkasunich> I think at least some of the hal_u8 usage is the latter case
[21:12:23] <jmkasunich> jepler: are __u8 and friends a kernel header thing, or a universal (gcc) thing?
[21:13:38] <jepler> jmkasunich: that's a linux kernel thing
[21:13:54] <jmkasunich> is there a suitable alternate for user space?
[21:13:59] <jepler> there's <inttypes.h> that is in the newest C++ standard but it's not in old compilers
[21:14:05] <jepler> uint8_t etc
[21:14:47] <jmkasunich> I suppose rtapi.h could define some types, or include inttypes.h, as needed
[21:15:18] <SWPLinux> we still end up with issues in format strings
[21:15:40] <SWPLinux> since those need to know the underlying size
[21:16:43] <jmkasunich> oh.... printf ( "foo: %d", foo ); simply can't work if foo is fixed size can it
[21:17:34] <SWPLinux> right
[21:17:42] <SWPLinux> that was most of jeplers 64-bit fixes, IIRC
[21:19:16] <jmkasunich> http://pastebin.ca/246925
[21:19:34] <jmkasunich> searched for pin/param _new calls
[21:19:39] <jmkasunich> _new and _newf
[21:19:50] <jmkasunich> not that many really
[21:20:27] <SWPLinux> yep, though there are also internally used hal_whatevers, probably to eliminate tons of casts
[21:20:56] <jmkasunich> yeah, but if we have proper fixed size types, those can and should be replaced
[21:21:25] <SWPLinux> but if we have proper fized size types, we don't need the hal_* types ...
[21:21:30] <SWPLinux> fixed
[21:21:35] <jmkasunich> yes and no
[21:22:12] <jmkasunich> Browns win! yay!
[21:22:38] <SWPLinux> I understand that having the HAL_types is good - they're useful macros at least
[21:22:42] <jmkasunich> yeah
[21:22:43] <SWPLinux> heh - oh joy :)
[21:22:59] <jmkasunich> it'd be even better if typechecking actually worked
[21:23:12] <SWPLinux> yeah
[21:23:30] <jmkasunich> if I do "typedef int foo", then declare a function that accepts a foo as an arg, I'd like the compiler to warn me if I pass an int
[21:24:17] <SWPLinux> C++ would do that
[21:24:37] <jmkasunich> I guess I was asking for that ;-)
[21:24:40] <SWPLinux> heh
[21:25:14] <SWPLinux> it also would allow you to specify get/set functions for parameters, so that internal variables could be automatically updated when a parameter changes, without all the if (param==old_param) stuff
[21:25:20] <jmkasunich> I'm tempted to start stripping out some of the "invisible" usage of those types
[21:25:47] <jmkasunich> (places where they're being used as fixed length types)
[21:26:36] <SWPLinux> like in m5i20?
[21:27:32] <jmkasunich> m5i20 actually declares 3 u16 params
[21:27:35] <jmkasunich> thats not invisible
[21:27:52] <SWPLinux> there are internal uses of u16 as well
[21:28:05] <jmkasunich> its the internal ones I want to tackle
[21:28:05] <SWPLinux> Device_DacWrite
[21:28:12] <jmkasunich> first we need some fixed length types
[21:29:17] <jmkasunich> does it make sense to define them in rtapi.h? that way you can use the same types in kernel or user space
[21:29:34] <SWPLinux> that's no different from hal_whatever, as far as I can see ...
[21:29:53] <jmkasunich> hal_whatever would be defined as using the fixed length types
[21:30:05] <jmkasunich> but hal_whatever would _only_ be used for pins and params
[21:30:17] <jmkasunich> right now, they are sometimes used for a random fixed length variable
[21:30:31] <jmkasunich> and if you go grepping thru the code, you find all kinds of false hits
[21:31:12] <jmkasunich> if in the future we change hal_float from a float to a double, it should affect only hal pins and params, _not_ other arbitrary items
[21:31:16] <SWPLinux> ok, and floats will be left alone (all floats, no doubles)
[21:31:32] <SWPLinux> wait - that's a problem
[21:32:04] <SWPLinux> unless you also make a variable type like "analog" that equivalent to a HAL_FLOAT
[21:32:13] <jmkasunich> why?
[21:32:45] <SWPLinux> if you don't, you end up with either lots of compiler warnings when people mix floats and doubles, or you end up with lost precision in drivers that declare floats for internal values
[21:33:09] <jmkasunich> the compiler doesn't complain when you mix floats and doubles
[21:33:26] <jmkasunich> I usually use (IIRC) doubles for temporary and internal vars in a component
[21:33:29] <SWPLinux> it should give a warning for assigning a double to a float
[21:33:44] <SWPLinux> since that results in a loss of precision
[21:33:58] <jmkasunich> hmm
[21:34:08] <jmkasunich> I'd have to go looking for that, maybe I cast
[21:34:13] <SWPLinux> you also don't know what to do with print format strings ...
[21:34:43] <jmkasunich> ok, I shouldn't have mentioned floats and doubles ;-)
[21:34:49] <SWPLinux> heh
[21:35:03] <SWPLinux> the same problem exists with ints, but they're quantifiable ;)
[21:35:05] <SWPLinux> (rimshot)
[21:37:54] <jmkasunich> heh. evoreg is really messed up
[21:37:59] <jmkasunich> hal_u16_t raw_counts[3];
[21:38:05] <jmkasunich> raw_counts[0] = (hal_u16_t) readw(port->io_base);
[21:38:16] <jmkasunich> oops, operator error
[21:38:34] <jmkasunich> thats not messed
[21:38:52] <jmkasunich> there is another place, where port->counts = an s16 cast of something
[21:38:55] <SWPLinux> readw - interesting
[21:39:19] <jmkasunich> port->counts is an s32
[21:44:08] <jmkasunich> jepler: does the fact that __u16 is a kernel thing mean that we can't use it.... because it will break a simulator compile?
[21:44:17] <jmkasunich> or are you providing those types somehow for the simulator
[21:45:58] <jepler> jmkasunich: on the systems I looked at, the <linux/types.h> has a userspace version which defines those types
[21:46:32] <jmkasunich> so they are _not_ kernel space only then...
[21:49:21] <jmkasunich> SWPLinux: there is another difference between __s32, and hal_s32
[21:49:24] <jmkasunich> the hal one is volatile
[21:49:30] <SWPLinux> yep
[21:49:53] <SWPLinux> I'm not sure C++ would differentiate volatile as a separate type :)
[21:51:02] <jmkasunich> one module done, N to go
[21:51:15] <SWPLinux> heh
[21:51:27] <SWPLinux> and N appears to fit into an 8-bit numbers
[22:07:54] <jepler> except needing the syntax 'set_out(...)' (instead of 'out = ...') it is not too much trouble to make bits in comp provide the 'canonical digital I/O' interface, with -not and -invert: http://pastebin.ca/246968
[22:10:03] <jmkasunich> jepler: I don't think we want canonicals for internal components
[22:10:50] <jmkasunich> that would just about double the length of the pin list but only a small fraction of those would be used
[22:11:13] <jmkasunich> perhaps some components might want inversion params or -not pins, but not the generic ones
[22:12:38] <jepler> and2 probably is a bad candidate
[22:12:59] <jepler> with my changes, you'd get a "bare bit" if you write "pin ... bit" and a "canon digital I/O" if you write "pin .. canonbit", so you have a choice
[22:14:45] <jmkasunich> what about "pin io canonbit" - that could get ugly (or would you prohibit it?)
[22:15:27] <jepler> right now it won't give you what you want but it's not flagged as an error
[22:15:45] <jepler> I'd fix it to be flagged as an error if I actually made this change
[23:03:29] <jmkasunich> hi don
[23:04:08] <dlabriola> good afternoon
[23:04:46] <dlabriola> I've been researching RTAI drivers - some dead leads, some luck
[23:08:07] <dlabriola> tossed one link for CAN based cheap motion control to the mail list - http://www.circuitcellar.com/flash2002/First/abstractM250.htm
[23:10:48] <dlabriola> https://mail.rtai.org/pipermail/rtai/2005-April/011192.html looks like good lead on hard RTE USB under RTAI
[23:12:41] <SWPLinux> you know - I have this feeling that all the serial-communications motor control systems just aren't really suited for coordinated motion
[23:13:16] <SWPLinux> I could be wrong about that, but I still have this gut feeling that there's just something wrong with them
[23:14:08] <rayh> SWPadnos, you mean like a common rt loop between distributed sets?
[23:14:30] <SWPLinux> no, more like sending separate commands to multiple single-axis "smart drivers"
[23:14:41] <SWPLinux> it just makes me itchy for some reason
[23:15:43] <SWPLinux> doing something like a G-Rex interface is OK, since the coordination of motion is in one location (on the G-Rex)
[23:16:42] <SWPLinux> if you can send updates fast enough, then the separate axis scheme is OK, but the updates need to be quick relative to the machining speeds
[23:21:03] <jmkasunich> or you need to have timestamps associated with the commands, and a common time bse
[23:21:03] <jmkasunich> base
[23:21:24] <SWPLinux> well, I think there are still issues, though nothing that excessive update rates can't cure
[23:21:48] <jmkasunich> heh, the purpose of those systems is to allow slow (non-hardRT) update rates
[23:21:55] <SWPLinux> consider accel - unless you specify the acc and vel profile for each move, you'll have each controller getting to speed at its own max rate
[23:22:00] <SWPLinux> heh
[23:22:24] <SWPLinux> I'm not sure that EMC scales accels between axes (based on the slowest axis used in the move)
[23:22:27] <jmkasunich> of course - you need to specify a velocity profile, not just a target position
[23:22:43] <SWPLinux> sure, but it has to include accel and vel, not just a "new vel"
[23:22:50] <jmkasunich> I'm just being devil's adovcate here - I _MUCH_ prefer the EMC approach
[23:22:53] <SWPLinux> sure
[23:25:42] <dlabriola> I've locked multi axis together (one running a program, the other as a slave over canbus) slaving between the units with a 2ms update, good motion following. The master sending its velocity and target postion, the slave set to interpolate over the 2ms period. - slave set to feedback position to master to to detect jams (as a dual motor gantry operation)
[23:26:16] <SWPLinux> what kind of speeds?
[23:26:42] <dlabriola> Ideal would be all built onto the PCI bus with dual port memory, but that makes for lots of wires
[23:26:46] <SWPLinux> heh
[23:27:00] <dlabriola> Had them running up to about 3kRPM
[23:27:32] <SWPLinux> hmmm - were you able to look at the speeds/positions with external measurement hardware (such as scopes and tachometers)?
[23:27:45] <rayh> SWPadnos said "not sure that EMC scales accels" It did when I was first testing the sherline rotary.
[23:27:54] <SWPLinux> ok
[23:28:25] <SWPLinux> I know it scales vels, and I assumed that accels would also be scaled, but wasn't sure
[23:28:53] <dlabriola> I was monitoring them over a 230k serial link - built into the units - looking over separate comms
[23:29:16] <SWPLinux> ok. I'm a pretty firm believer that you can't use a system to test its own perfoemance ;)
[23:29:22] <SWPLinux> performance
[23:30:11] <dlabriola> I've checked the methodology independently before. I have reasonable trust in it.
[23:31:00] <jmkasunich> SWPLinux: the stuff is known to work
[23:31:11] <SWPLinux> ok. I'm sure it works, but I just have these nagging thoughts that tell me it's not as accurate
[23:31:09] <jmkasunich> people do high speed packaging lines and such with it
[23:31:57] <SWPLinux> in cases where the endpoint is important, that's great. when the path is even more important, I see opportunity for trouble
[23:32:06] <rayh> I'm with swp. A packaging line can have a lot more slop between motors than a milling machine cutting a circle.
[23:32:09] <SWPLinux> unless you can send a full profile specification every update
[23:33:11] <rayh> "The servo position is maintained as a 48 bit number in order to have a full 32 bit position and have a 16.16 fractional commanded velocity."
[23:33:31] <SWPLinux> I saw that
[23:33:43] <SWPLinux> plus they finally have a PIC that knows what a carry bit is :)
[23:34:38] <dlabriola> The system I used is not from the article, but based on TMS320F2406 - similiar idea though.
[23:35:13] <SWPLinux> for a positioning system, I'm all over that method
[23:35:20] <SWPLinux> for a path following system, not so much
[23:35:35] <alex_joni> hey all
[23:35:46] <SWPLinux> hi Alex
[23:35:55] <alex_joni> * alex_joni finally made it to the hotel :)
[23:36:38] <alex_joni> seems you've been busy
[23:39:25] <SWPLinux> some
[23:39:34] <alex_joni> yeah.. too much to read right now :(
[23:40:37] <SWPLinux> well, just skip to the end of each topic :)
[23:41:25] <jmkasunich> well, in a few minutes, hal_s16_t and hal_u16_t are going to be a thing of the past....
[23:41:56] <alex_joni> yay
[23:42:00] <alex_joni> ;-)
[23:42:09] <alex_joni> seen ppmc work on #emc
[23:42:16] <alex_joni> and some talk about the CAN drivers here
[23:42:16] <jmkasunich> yeah
[23:42:39] <SWPLinux> mostly theoretical, I think
[23:42:44] <SWPLinux> at least on my end :)
[23:42:55] <alex_joni> you're always theoretical
[23:42:58] <alex_joni> :P
[23:43:13] <SWPLinux> :P
[23:43:42] <SWPLinux> "I'm thinking about it, therefore I might be"
[23:44:16] <alex_joni> ok, guess you got a good grip on everything
[23:44:22] <alex_joni> may I be excused? :)
[23:44:25] <dlabriola> there is some tradeoff between the position update rate and servo update rate. How tight does the PID in EMC2 typically track.?
[23:44:39] <jmkasunich> depends on how well you tune it
[23:44:54] <jmkasunich> usually 1 or 2 encoder counts
[23:44:55] <alex_joni> dlabriola: it stays under ferror :)
[23:44:55] <SWPLinux> generally, the PID runs at a 1ms rate, but some have gotten it up to ~8 KHz
[23:45:11] <SWPLinux> on all axes simultaneously
[23:45:24] <jmkasunich> 1-2 counts is probably optimistic on second thought
[23:45:33] <jmkasunich> at least during agressive movement
[23:45:44] <alex_joni> might be true on cruises
[23:45:52] <alex_joni> definately when it's stopped :D
[23:46:16] <dlabriola> What kind of encoder resolutions?
[23:46:23] <alex_joni> good night guys..
[23:46:33] <SWPLinux> see you alex
[23:46:48] <SWPLinux> jon elson runs one machine at 128000 steps/inch
[23:47:20] <SWPLinux> I think he said that one stays within a few counts (some few microns)
[23:47:36] <dlabriola> impressive - especially if tuned to a few counts!
[23:47:42] <jmkasunich> jepler: you around
[23:47:54] <jepler> jmkasunich: yes
[23:48:05] <jmkasunich> I'm being lazy - how does conv.comp.in decide what flavors to generate?
[23:48:12] <jepler> it's in the Submakefile
[23:48:15] <jmkasunich> I want to remove the s16 and u16 ones from the list
[23:48:30] <jmkasunich> thanks
[23:48:38] <jepler> you probably have to remove the generated files as well
[23:48:42] <jepler> otherwise they'll be picked up by the "get all .comps" step
[23:48:48] <jmkasunich> make clean should do that, right?
[23:49:15] <jepler> I am not sure if I fixed 'make clean' to do that
[23:49:26] <jepler> rm conv_*.comp in components/ will, if make clean doesn't
[23:49:35] <jepler> anyway, just remove the items from CONVERTERS :=
[23:49:53] <jmkasunich> right
[23:50:04] <jepler> you can remove the rule further down if you want but leaving it shouldn't hurt anything
[23:50:11] <jepler> (there's one rule for each converter, because they're all a bit different)
[23:51:15] <jmkasunich> I'll remove them - I hate leftovers
[23:51:59] <jepler> that's fine with me -- there's always CVS
[23:52:34] <jmkasunich> someday in the not to distant future I want to get rid of u8 as well
[23:52:47] <jmkasunich> then maybe rename u32 and s32 as u and s
[23:53:23] <jepler> that will sure cut down on the number of converters
[23:54:13] <jmkasunich> yep
[23:54:24] <jmkasunich> it does look like make clean removes the converters
[23:54:34] <jepler> good
[23:55:47] <jmkasunich> oops, I think I deleted one too many
[23:55:50] <jmkasunich> bit->float is missing
[23:55:55] <jepler> I wonder if we should go a step further and only make the converters that go through the 32-bit types (uXX <-> u32, u32 <-> s32, s32 <-> sxx, x32 <-> float
[23:56:31] <jmkasunich> I dunno
[23:56:34] <jepler> (bit being a uXX in my mind)
[23:56:40] <jmkasunich> something strange is happening
[23:57:05] <jmkasunich> never mind...
[23:57:04] <jepler> uh oh -- and I'm about to be called to the dinner table.
[23:57:07] <jepler> oh good
[23:57:25] <jepler> see you later
[23:57:30] <jmkasunich> there -was- no conv_bit_float.comp generated, but it magically appeared as I was typing
[23:57:34] <jmkasunich> enjoy dinner