Back
[00:00:04] <voxadam> http://www.linuxcnc.org/docs/EMC2_Integrator_Manual.pdf
[00:00:16] <voxadam> http://www.linuxcnc.org/content/view/5/5/lang,english/
[00:00:19] <jepler> and you're looking at the git 'master' branch?
[00:00:26] <voxadam> I am.
[00:00:53] <jepler> the hal_m5i20 driver is removed in 'master', because the hostmot2 driver for 5i20 cards is stable and has many more features.
[00:01:24] <voxadam> I was starting to wonder.
[00:01:59] <jepler> even so I think the path is wrong for v2.4..
[00:02:26] <voxadam> http://git.linuxcnc.org/gitweb?p=emc2.git;a=tree;f=src/hal/drivers;h=f1ce4eb5a5d96aa49cce385a1a998f544a3ff088;hb=master
[00:03:03] <voxadam> Oops... I didn't mean to paste that.
[00:03:49] <jepler> in v2.4_branch the path is src/hal/drivers/m5i20/hostmot5_src/REGMAP4E
[00:04:16] <voxadam> Thanks.
[00:04:44] <jepler> *however* the register map for hostmot2 is entirely different..
[00:05:23] <jepler> the one that I think is accurate for hostmot2 is src/hal/drivers/mesa-hostmot2/doc/regmap
[00:05:33] <jepler> same path in the v2.4_branch and master branches
[00:07:17] <voxadam> Are the quadrature counters for the encoders implemented in HOSTMOT2 or EMCMOT?
[00:07:36] <jepler> in hostmot2.
[00:07:50] <jepler> are you looking for info on how to use index mask with hostmot2?
[00:08:28] <jepler> (since that's what the surrounding text is about..)
[00:08:29] <voxadam> I'm looking for info on a number of different things at the moment. Index masking is one of those things.
[00:09:40] <jepler> OK, I can help with that
[00:09:56] <jepler> is 5i20 your card?
[00:11:05] <jepler> for index mask support, choose one of the firmwares with IM in the name, such as SVST8_4IM2.
[00:11:26] <voxadam> At the moment my card is purely theoretical as I don't own one at the moment. I'm looking deeper into EMC for someone with a mid-80s Mori that is thinking about replacing the old Yasnac control with EMC.
[00:11:34] <jepler> Refer to the PIN file for the location of the index mask pins (P4 pins 1, 3, ..., 15)
[00:12:18] <jepler> to actually enable use of the index mask, use a line in one of your hal files like: setp hm2_pci.0.encoder.00.index-mask 1
[00:12:39] <jepler> to use the opposite polarity for the mask, add another line for index-mask-invert
[00:13:26] <jepler> I don't use index mask myself, but I know cradek does at least on his HNC
[00:14:50] <voxadam> After I do some more digging I'll probably have to pick cradek's brain. The Mori he retrofitted is the little brother to the Mori I'm looking at.
[00:15:17] <jepler> yeah
[00:17:41] <voxadam> Does EMC support Mesa daughter cards like the 7I34 eight channel RS-485 interface?
[00:18:47] <jepler> voxadam: on JR, cradek uses spindle orient for tool change but not for rigid tapping. If you have a way to confirm that the spindle is oriented (handshake or timeout) it should be just fine if it's not RT.
[00:20:00] <jepler> voxadam: for rigid tapping, he uses an encoder only and doesn't use orient. The design of emc's single point threading and rigid tapping is to use the index pulse from the spindle encoder to detect the "zero degree" angle, but since rigid tapping is one pass only you don't even need multiple rigid taps to start at the same angle
[00:20:03] <voxadam> Thanks... I figured that's what alex_joni was saying.
[00:20:18] <jepler> .. so because the only way he could manage to mount a spindle encoder was on the motor, not on the spindle, the index never lines up the same anyway
[00:21:09] <voxadam> That's what I was thinking.
[00:21:37] <voxadam> Retrofitting is so much fun. So many workarounds, so little time (and I/O).
[00:22:02] <jepler> actually he talked about hooking up one of the phases to the index input so that it would never even wait to start a tap
[00:25:10] <jepler> as for the 7i34 - you can use it to get differential signalling, but actually doing serial communication on it is not implemented in our driver or available in any of the firmwares we ship
[00:25:55] <jepler> so for instance it's not an option for communicating with a modbus device at 1Mbps serial or the like
[00:26:03] <voxadam> What phy interface do people use for modbus?
[00:26:18] <voxadam> PCI serial card?
[00:26:23] <jepler> I understand that classicladder has support for any linux serial device plus ethernet
[00:26:32] <jepler> so that would include on-board serial, PCI serial, USB serial
[00:27:05] <SWPadnos> the library used by other HAL drivers (gs2_vfd at least) is also supposed to support ethernet
[00:27:26] <SWPadnos> as well as any serial device known to Linux
[00:27:32] <jepler> SWPadnos: I think gs2_vfd is all
[00:27:44] <SWPadnos> I thought there was another one someone had written
[00:28:00] <jepler> maybe so but I don't recall it
[00:28:28] <voxadam> I'm looking to possibly push as much I/O that doesn't require bounded latencies off to modbus so that I can hopefully avoid using a 5I22 or a second 5I20.
[00:28:36] <SWPadnos> I wonder if it was something I was working on (briefly) for the VFD on the Tormach or something
[00:28:41] <SWPadnos> not quite modbus
[00:28:58] <jepler> if you happen to already have the modbus I/O I don't blame you for thinking that way
[00:29:19] <SWPadnos> minor design point - the more stuff you stick on modbus, the higher the latency will be
[00:29:20] <voxadam> It's good to know that I'm not crazy. :)
[00:29:35] <jepler> I wish I felt like the classicladder modbus implementation was solid .. dave911 has had negative experiences (but has a patch that we're working towards including in a future version)
[00:29:44] <jepler> and personally I don't have modbus hardware
[00:29:56] <SWPadnos> I don't know if multiple devices are truly supported on a single serial port
[00:30:07] <SWPadnos> I know they should be, but I don't know that it works correctly
[00:30:09] <jepler> (but cradek might like it -- he has some of those automationdirect vfds with modbus and I think it might give him accurate spindle speed control, in contrast to the 0-10V method)
[00:30:12] <voxadam> Hmmm.... That's problematic.
[00:30:33] <SWPadnos> something to check, I'm not pointing out a suspected bug, just a point to be sure of
[00:31:34] <voxadam> If we do go that route I'm sure there will be plenty of checking... CL's modbus support is barely documented and rarely talked about.
[00:35:02] <voxadam> Time to reboot. Every time I'm notified of an OS update that requires me to reboot it makes me seriously think about Linux on the desktop.
[00:35:18] <SWPadnos> heh
[00:35:34] <SWPadnos> I just use Windows 2000 - no more pesky updates
[00:35:56] <voxadam> Just recently upgraded from NT4 I assume.
[00:36:00] <Jymmm> lol
[00:36:08] <SWPadnos> no, never used NT on a real machine
[00:36:13] <SWPadnos> 3.51 or 4
[00:36:20] <Jymmm> 3.50
[00:36:28] <SWPadnos> (had OS2 Warp though, as well as NextStep and beOS)
[00:36:43] <Jymmm> still have warp3
[00:36:57] <SWPadnos> I started out (personally anyway) with 4
[00:36:59] <voxadam> My first experience was with CP/M on a Z80.
[00:37:02] <SWPadnos> had 3 at work though
[00:37:20] <Jymmm> APPLE IIe, then TRS80
[00:38:28] <SWPadnos> Apple (the Bell&Howell black ones), Atari, Exidy Sorcerer, some Coleco, TRS80, TI 99/4A, etc etc
[00:39:05] <Jymmm> Coleco Vision!!!
[00:39:44] <SWPadnos> not colecovision, some other color thing that wasn't a Radio Shack CoCo
[00:40:11] <Jymmm> 12 butotn keypad + joystick on a coiled cord?
[00:40:21] <SWPadnos> hmmm, maybe it wasn't a Coleco at all
[00:40:35] <SWPadnos> it's been a number of years (decades), I may have forgotten
[00:40:52] <Jymmm> SWPadnos: You know you stil have it =)
[00:40:56] <SWPadnos> heh
[00:41:03] <SWPadnos> nope, I think I only have the Atari
[00:41:09] <Jymmm> 2600?
[00:41:15] <SWPadnos> only the Atari 800XL and the TI were mine, the others were at school
[00:41:23] <SWPadnos> had one of those
[00:41:29] <Jymmm> had or have?
[00:41:35] <SWPadnos> and an NEC Turbo GraphX
[00:41:41] <SWPadnos> had, I'm pretty sure
[00:42:01] <Jymmm> Bummer, I'd buy the Atari 2600 from ya
[00:42:13] <SWPadnos> if I have it, I'll send it to you
[00:42:19] <Jymmm> cool
[00:42:33] <SWPadnos> I'm reasonably sure I don't, but you can dream ;)
[00:42:48] <Jymmm> LOL, that works.
[01:00:17] <mozmck> jepler: about not being able to compile, I had the same problem after the linux-headers got reinstalled. I just installed my header packages again and was able to compile.
[01:04:31] <jepler> mozmck: makes sense to me -- the apt_preferences 'pin' will make it not be offered as an update
[01:04:41] <jepler> I assume now you get prompted to install the new one every time update manager pops up
[01:38:23] <mozmck> jepler: I do here because I still have the standard kernel installed as well.
[01:39:22] <mozmck> alex_joni suggested making the version number higher so it stays on the top of the list, and it would also keep the headers from being overwritten.
[01:41:18] <mozmck> something like 2.6.32-99-rtai, or maybe I could add 100 to the ubuntu revision number so that if it's based on the ubuntu 2.6.32-22-generic mine would say 2.6.32-122-rtai
[02:08:09] <skunkworks> where are people staying at the fest?
[02:10:32] <SWPadnos> Hampton Inn Ann Arbor North
[02:10:38] <SWPadnos> for me anyway
[02:13:23] <SWPadnos> I think some others are staying at the Microtel
[02:16:56] <jepler> mozmck: if we really want to be antisocial we could make it a whole epoch later
[02:17:36] <mozmck> :) Do you not like the idea then?
[02:17:39] <jepler> in a version like 1:2.6.32... the 1: is often not shown but it is newer than anything from the earlier (unnamed) epoch
[02:17:43] <jepler> welllllll
[02:18:05] <jepler> I am unhappy that the patched-kernel-specific headers go in the common headers package, that's the cause of this problem
[02:18:21] <jepler> but I am way too out of it to know if there's a packaging solution to put the headers where they need to go
[02:18:28] <jepler> so I don't have anything to offer but the current suggestion
[02:18:42] <jepler> epoch has the advantage of not showing a confusing version to the user
[02:18:59] <jepler> but that's about it
[02:21:30] <mozmck> ah, I didn't know about the epoch. I presume you're calling the 1: that?
[02:22:29] <jepler> yes
[02:22:37] <jepler> http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version
[02:22:39] <mozmck> there are two headers packages, and I had assumed that anything changed when in the one labeled rtai, but apparently not.
[02:24:02] <mozmck> which makes sense since some of the standard kernel headers are modified in the patch, and would be overwritten by the generic package.
[02:25:10] <jepler> from ubuntu there's linux-headers-2.6.32-22 and linux-headers-2.6.32-22-generic
[02:25:26] <jepler> I think that the modified headers went in linux-headers-2.6.32-22 but were then overwritten when ubuntu released a new version of it
[02:25:52] <mozmck> I'm not sure that 2.6.32-122... is more confusing than 2.6.32-22...
[02:26:12] <mozmck> yes, I think you're right there.
[02:27:27] <jepler> of course that assumes you can figure out how to specify an epoch to the kernel building stuff
[02:28:29] <mozmck> I think modifying the debian revision would have the benefit of having completely separate packages for the rtai kernel.
[02:28:58] <mozmck> and it wouldn't interfere with compiling stuff for the ubuntu kernels
[02:30:11] <jepler> I agree; since the linux-headers-2.6.32-22 (or -122) package won't work if replaced by one built by ubuntu, we need to make sure they have either package names that are distinct or package version numbers where ours wins
[02:32:20] <jepler> hm, does the -122 have to be a number? If not we could put -linuxcnc22 or something
[02:33:33] <mozmck> I think that would work. I'll have to try it.
[02:33:55] <jepler> hm I think I got side tracked a bit, since linux-headers-2.6.32-22 is a package name; its version is something like 2.6.32-21.32. you started talking about selecting distinct package names and I got off on selecting higher version numbers
[02:34:07] <mozmck> I know if I put ...-22_rtai the compile barfs in one place.
[02:34:08] <jepler> distinct package names is the better idea
[02:34:42] <jepler> _ may be a forbidden character in a package name
[02:35:12] <mozmck> It doesn't work for the ubuntu build setup anyhow.
[02:36:28] <jepler> 'night
[02:36:31] <mozmck> yeah, I was talking about the package name. The version is somewhat part of that I think.
[02:36:34] <mozmck> night.
[04:01:07] <SteveStallings> SteveStallings is now known as steves_logging
[11:59:06] <CIA-2> EMC: 03jthornton 07v2.4_branch * ra8e9cb1989d8 10/docs/src/lathe/lathe-user.lyx: add info about arcs and update tool table info
[18:07:15] <micges> today I was using mozmck rtai kernel to drive real machine, everything was ok but after 6~8 emc starts realtime doesn't unload and futher load emc wasn't possible
[18:08:18] <micges> no trace on dmesg and this happened few minutes after I've unplugged ethernet cable
[18:08:39] <micges> any ideas, clues?
[19:26:49] <mozmck_work> micges, does it happen with the ethernet cable plugged in?
[19:34:59] <micges> maybe, I didn't pay attention
[19:36:35] <micges> it was few minutes before work end, so I'll debug it tomorrow, today I'm asking if someone noticed something simmilar
[19:39:50] <mozmck_work> I haven't, but I haven't started and stopped emc that many times lately.
[19:40:54] <micges> it was attempt to machine integration with 10.04, so many emc restart is needed
[19:45:07] <mozmck_work> Yeah. I don't have an idea. I have a problem (and I think someone else did as well) getting emc to load the realtime at all on a computer with more that 2 cores. I can run the rtai kernel latency test once after booting but not again.
[19:45:18] <mozmck_work> I haven't had time to try and debug that.
[19:48:28] <SWPadnos> mozmck_work, using ISOLCPUS (or the equivalent)?
[19:52:20] <micges> my is dual core, so can I try isolcpus ?
[19:52:55] <SWPadnos> you can try. I think there was a recent discussion, and maybe a patch, about which CPU the RT tasks should be assigned to
[19:53:00] <SWPadnos> I don't recall the outcome
[19:53:31] <SWPadnos> is it an Intel? if so, and HyperThreading is on, it will look like 4 cores
[19:53:54] <micges> yep Intel
[19:53:55] <SWPadnos> in which case I think you'd want isolcpus=3
[19:53:57] <SWPadnos> ok
[19:54:22] <micges> I think ht should be disabled for rt
[19:54:25] <SWPadnos> you can probably disable hyperthreading (in the BIOS), it often doesn't help much
[19:54:42] <SWPadnos> I don't think it's necessary, but it may be somewhat helpful
[19:54:53] <SWPadnos> it probably depends on which CPU generation you have
[19:55:17] <micges> e5300
[19:55:52] <SWPadnos> whatever that means :)
[19:56:13] <Jymmm> XT generation
[19:56:25] <SWPadnos> NeXT generation!
[19:56:42] <Jymmm> no paraport
[19:56:50] <SWPadnos> LASER CARD READER!
[19:57:02] <Jymmm> Just SCSI
[19:57:24] <Jymmm> and ethernet
[19:58:05] <SWPadnos> fast ethernet, I'll bet
[19:58:31] <Jymmm> I think just 10-BaseT
[20:00:18] <alex_joni> 10-Base2 ?
[20:00:30] <Jymmm> probably
[20:01:03] <alex_joni> maybe it's already twisted pair
[20:01:13] <alex_joni> 1Base5 even
[20:01:21] <Jymmm> No, not that bad
[20:01:27] <SWPadnos> allyourBasearebelongtous
[20:01:46] <SWPadnos> that was arcnet speed
[20:01:50] <SWPadnos> 1.5 MBit/sec
[20:01:55] <SWPadnos> IIRC
[20:02:39] <alex_joni> 1Base5 was 1Mbit
[20:03:05] <alex_joni> StarLan afaik
[20:03:21] <andypugh> jepler: I got Excel to make the 48 combinations. As expected there are two that work properly in opposite directions, (15 and 44 in this case) and a few than rotate the motor badly.
[20:06:41] <jepler> andypugh: I also fiddled with a program to generate the tables -- but of course I don't have a motor to test it with.
http://emergent.unpy.net/files/sandbox/mkphasetable.py
[20:06:50] <jepler> bbl
[20:10:37] <andypugh> For comparison, done with Excel and a lot of auto-fill. (and converting to google docs has broken it, I think)
[20:10:39] <andypugh> https://spreadsheets.google.com/ccc?key=0AhjJW1-T6n7CdE9aQ043d2plalBUaXZ1aE90b1JsTUE&hl=en#gid=0
[20:11:04] <mozmck_work> SWPadnos: I tried isolcpus but it didn't help.
[20:11:12] <SWPadnos> ok, just curious
[20:11:31] <SWPadnos> RTAPI used to use the highest numbered CPU for RT tasks, I don't know if that was changed recently
[20:11:46] <SWPadnos> for your new machine, that would be #5 (so isolcpus=5)
[20:12:14] <mozmck_work> jepler had a patch that would let rtai determine the cpu the realtime stuff ran on, but I didn't try that because the rtai tests themselves fail.
[20:12:23] <mozmck_work> yeah, 5 is what I used.
[20:12:27] <SWPadnos> ok
[20:12:58] <SWPadnos> RTAI already has support for choosing which CPU to use, I think RTAPI always used the highest numbered one
[20:13:13] <mozmck_work> I might try vulcano or magma in case it's a bug in rtai 3.8.1
[20:13:45] <mozmck_work> Yes, I believe it does. but the rtai kernel latency test at least used cpu 0
[20:14:00] <mozmck_work> if I recall correctly...
[20:14:06] <SWPadnos> sure, or "whichever one it was stuck on" :)
[20:14:59] <SWPadnos> here we go, for a lightweight distro:
http://tinycorelinux.com/
[20:15:37] <SWPadnos> runs out of CPU cache, on modern CPUs :)
[20:15:45] <SWPadnos> (or is small enough to do so anyway)
[20:29:19] <mozmck_work> interesting! I've looked at fltk some. I like what I've seen so far.
[20:29:54] <andypugh> A friend of mine has a compact linux distro, well, he did until Intel bought him :-)
[21:00:28] <andypugh> I see that comp.g looks to handle a "modparam" tag. is it supported or a vestigial remnant of what became "personality"?
[21:35:17] <voxadam> I have to wonder how many people have been fitted for straight jackets as a direct result of ladder logic. Maybe I'm just not used to it yet.
[21:36:09] <JT-Hardinge> what's the problem voxadam ?
[21:36:39] <voxadam> No real problem... I'm just reading about ladder. I don't have any previous experience with it.
[21:38:18] <JT-Hardinge> in ladder the last output wins
[21:48:42] <alex_joni> ha
[21:49:01] <alex_joni> btw, you don't _have_ to use ladder..
[21:49:28] <alex_joni> classicladder does more than just ladder
[21:49:29] <voxadam> How do you avoid it?
[21:49:34] <alex_joni> but the alternatives are worse
[21:49:38] <voxadam> Python? C/C++?
[21:50:29] <alex_joni> no.. grafcet was the name I tried to recall
[21:50:55] <alex_joni> looks like this:
http://upload.wikimedia.org/wikipedia/commons/3/3d/Secuencial_GRAFCET.PNG
[21:52:14] <voxadam> I'm imagining the endless possibility of race conditions in ladder.
[21:52:36] <voxadam> I guess it just takes experience.
[21:52:43] <alex_joni> also known as SFC = sequential function chart
[21:52:54] <alex_joni> http://en.wikipedia.org/wiki/Sequential_function_chart
[21:53:12] <alex_joni> I did some coding in SFC a while ago, and it's not fun
[21:53:20] <alex_joni> ladder is quite easy once you get it..
[21:53:27] <alex_joni> just read/write it left to right :D
[21:53:29] <JT-Hardinge> voxadam: use do this - done with this - do next in ladder
[21:53:46] <alex_joni> voxadam: start with one line rungs
[21:53:53] <alex_joni> then move over to more complex things
[21:54:09] <voxadam> I'm sure I'll get used to it.
[21:57:54] <JT-Hardinge> does G76 work with the spindle turning backwards?
[21:58:31] <alex_joni> JT-Hardinge: I don't think so
[21:59:04] <JT-Hardinge> oh crap I'm screwed now
[21:59:41] <andypugh> I guess negative pitch, even if it works, doesn't give the tool enough runup?
[22:00:40] <andypugh> JT-Hardinge: Just lie about the encoder scale for the length of the job, ie negate it. Then you should be OK with the tool at the back.
[22:01:23] <JT-Hardinge> andypugh: I don't follow
[22:02:20] <JT-Hardinge> I still have to run my spindle backwards on this part
[22:02:38] <andypugh> If G76 doesn't work with the spindle running backwards, don't let the lathe know. negate the scale of the spindle encoder, put the tool at the back, run the spindle backwards and set up as for an internal thread.
[22:03:00] <andypugh> G76 will think the spindle is running forwards.
[22:03:26] <voxadam> You're quite the workaround artist...
[22:06:50] <JT-Hardinge> andypugh: that didn't seem to change anything
[22:06:57] <andypugh> Hmm.
[22:07:08] <andypugh> What happens?
[22:07:38] <JT-Hardinge> was that suppose to make the spindle change directions ie M3 run backwards?
[22:08:29] <andypugh> No, just meant to make G76 think that the spindle was running forwards when it was running backwards, so that it advances towards the chuck as the encoder count increases.
[22:09:18] <JT-Hardinge> well it did do that for sure cause it is running some air threads atm
[22:09:30] <andypugh> You would still need to run the spindle in reverse, but I doubt G76 looks at M3/M4
[22:10:26] <JT-Hardinge> ok, I'll just have to run the threads in a separate program I guess
[22:10:42] <andypugh> I am assuming that G76 expects to see an increasing count, that's all.
[22:10:45] <JT-Hardinge> andypugh: thanks for the quick workaround
[22:11:56] <andypugh> For a longer term one, you could perhaps set up a DIO pin that switches a factor in HAL to reverse the spindle encoder.
[22:13:23] <andypugh> That might need two encoders, and the DIO would switch a MUX that links one or the other to *.spindle-position or whatever the pin is called.
[22:13:38] <JT-Hardinge> better to fix EMC so G76 works on both front and back threading
[22:19:58] <JT-Hardinge> there we go and have some 1 5/8-20 UN-2B Left Hand External Threads on the part
[22:24:03] <JT-Hardinge> andypugh: thanks again you saved my ass
[22:24:31] <andypugh> Glad it worked, it was pure speculation :)
[22:27:36] <voxadam> Is there a master "todo" list for things that need to be fixed or implemented in EMC (like back threading using G76)?
[22:28:10] <andypugh> There is something on the Wiki, yes.
[22:28:17] <cradek> * cradek blushes
[22:28:34] <cradek> that's an ooold bug - I forgot about it.
[22:28:36] <andypugh> But I don't think left-hand threading is mentioned.
[22:29:01] <voxadam> Has anyone ever entertained the idea of a bug tracker?
[22:29:15] <cradek> we have one
[22:29:41] <SWPadnos> feature requests aren't bugs though :)
[22:30:05] <cradek> thee problem isn't LH, it's M4
[22:30:08] <voxadam> Call it an "issue tracker" then.
[22:30:11] <SWPadnos> I'm working on a list of enhancements though, I suppose I should merge it with the list(s) on the wiki
[22:30:31] <SWPadnos> we have both actually, but people often don't categorize things correctly
[22:30:42] <SWPadnos> for my version of correct, anyway :)
[22:32:53] <cradek> JT-Hardinge: I'll fix that in 2.4.2 fwiw
[22:32:58] <andypugh> Am I right in thinking that there is no fixed phase relationship between software pwmgen instances? ie they all run independently and don't share a clock?
[22:33:14] <SWPadnos> HAL threads are effectively a master clock
[22:33:57] <JT-Hardinge> cradek: thanks
[22:33:59] <SWPadnos> which doesn't exactly provide a fixed phase relationship
[22:34:00] <andypugh> So two 50% PWMs will start in phase, and stay in phase?
[22:34:24] <SWPadnos> I don't think there's any guarantee of that
[22:34:33] <andypugh> No, I was assuming not.
[22:34:58] <SWPadnos> they won't "beat", since they have the same master clock, but they may get out of sync by a base period
[22:35:00] <voxadam> That reminds me.... what does HAL use as its clock source? The guy I'm working with is worried that some sort of archaic x86 hardware specific/dependent clock source is used.
[22:35:30] <SWPadnos> voxadam, whatever is available, either the 1.19MHz clock, or a high resolution timer if that's available
[22:35:47] <voxadam> HRTs are used if compiled though?
[22:35:51] <andypugh> Other implementations I have seen use a count-up count-down clock and switch at a certain point, so a set of PWMs which share the clock but have different duty cycles will be in phase. The HAL one seems to work in a slightly more "ad-ho" way.
[22:35:53] <cradek> what at odd worry
[22:35:59] <voxadam> Agreed.
[22:36:04] <SWPadnos> if available, support is already included
[22:36:20] <SWPadnos> that is a bit like being worried that the resistors are those old archaic carbon ones
[22:36:28] <voxadam> I think he read some old emc1 related docs, posts.
[22:36:49] <voxadam> I'm just trying to alleviate his worries.
[22:37:27] <cradek> tell him to check youtube?
[22:37:33] <voxadam> He's not 100% comfortable with the idea of EMCMOT being implemented in software. He prefers hardware.
[22:37:52] <cradek> no cnc control is implemented in hardware
[22:38:11] <voxadam> I understand that.
[22:38:34] <SWPadnos> software - putting the first "C" in "CNC" since the '70s or so
[22:39:03] <cradek> and thank history for that
[22:39:35] <voxadam> I think he's getting more comfortable with the idea. I spent some time explaining how RTAI/ADEOS works and that Linux is a preemtable thread.
[22:40:06] <SWPadnos> out of curiosity, what alternatives does he think he has?
[22:40:11] <SWPadnos> (to software control)
[22:41:07] <voxadam> I've had this problem in the past... People seem to think that because it's implemented on a dedicated micro that it's "hardware based" when in fact it is in no way such.
[22:41:16] <andypugh> Jaquard cards?
[22:41:28] <alex_joni> softdmc
[22:41:31] <cradek> I can understand someone wanting cranks instead of cnc, but to be scared if the x86 timer in particular is just weird
[22:41:32] <SWPadnos> yeah, that's the thing
[22:41:51] <SWPadnos> if you open up a Fanuc, Delta Tau, Heidenhein, whatever, you find a PC
[22:41:52] <cradek> of
[22:41:56] <SWPadnos> often running Windows
[22:42:02] <cradek> dang phone kb
[22:42:04] <SWPadnos> heh
[22:42:21] <alex_joni> heh, was wondering what was up with cradek's typing today
[22:42:36] <cradek> haha yep
[22:42:44] <SWPadnos> you're not on the road already, are you?
[22:42:45] <alex_joni> SWPadnos: btw, our robots use winxp for the GUI part
[22:42:51] <voxadam> For some reason having a little Galil "black box" is comforting to people.
[22:42:59] <SWPadnos> sure
[22:43:03] <alex_joni> mixed with some non-free RT for the planners though..
[22:43:22] <voxadam> The idea of RT on an OTS x86 box scares the sh*t out of people.
[22:43:48] <SWPadnos> well, you can spend as much as you want getting the hardware more reliable
[22:43:58] <cradek> that's not universal
[22:44:02] <SWPadnos> (with asymptotic reliability/cost)
[22:44:28] <SWPadnos> right - not that it gets much more reliable, but it can still cost about as much as you're willing to spend
[22:44:35] <voxadam> RTAI is mature, SMI can be disabled and systems can be profiled. RTAI/Linux is the way of the future.
[22:44:46] <SWPadnos> and the present
[22:44:46] <voxadam> And, the future is now.
[22:45:04] <cradek> it sure gives us a flexible powerful system
[22:45:36] <SWPadnos> bbl
[22:46:24] <voxadam> I can't read any more about PLCs and ladder. Time for some BBQ and beer.
[22:49:05] <JT-Hardinge> voxadam: I'll be over as soon as these last few parts are done
[22:49:14] <voxadam> :D
[22:52:11] <andypugh> Can comp handle compound logic in the "if personality == " lines?
[22:56:50] <SWPadnos> it can do things like if (personality & 0xF0) I think
[23:01:03] <JT-Hardinge> ok, the first part took 3 weeks the second one tool 45 minutes or so
[23:02:40] <alex_joni> voxadam: I somehow doubt RTAI/Linux is the way of the distant future
[23:02:55] <andypugh> SWPadnos: Yes, so either I choose my type codes to suit boolean logic, or I just have lots of doubled-up lines.
[23:02:57] <alex_joni> at least not the way current HW design is going
[23:03:17] <alex_joni> modern PCs are less and less suitable for realtime stuff.. too many gimicks inside
[23:03:20] <SWPadnos> more likely an ARM or AVR32 or something
[23:03:38] <alex_joni> or a less potent processor..
[23:03:50] <alex_joni> look how great the Atom is working for RT
[23:04:04] <SWPadnos> I wonder how much Intel is trying to make Atoms better for RT, vs. low power media processors
[23:04:35] <alex_joni> I seriously doubt they take RT in consideration when designing any new processor
[23:04:58] <SWPadnos> that's probably true
[23:05:01] <SWPadnos> sadly
[23:05:05] <SWPadnos> probably sadly
[23:05:27] <alex_joni> well.. dunno
[23:05:40] <alex_joni> not really an interesting share of the market
[23:05:54] <alex_joni> RT applications are probably less than 0.01% or so ;)
[23:08:01] <alex_joni> anyways, got a high priority task ready to preempt me
[23:08:04] <alex_joni> good night all
[23:08:07] <SWPadnos> see you :)
[23:09:14] <JT-Hardinge> good night
[23:21:47] <andypugh> is there a default "personality"?
