Back
[00:31:21] <cradek> jepler: currently the canon SET_ORIGIN_OFFSETS() is the sum of both g5x and g92. the assumption that they get combined is everywhere in all the layers. if we want g5x -> rotate -> g92, I think they need to be separated
[00:35:12] <cradek> (... which would be ok anyway, so the guis can tell the difference)
[00:44:48] <jepler> cradek: ugh
[00:46:37] <cradek> if I'm going to fuxx that all up, it's tempting to change it all so CANON is in machine coords
[00:46:53] <cradek> but I wonder what (simple, minimal) thing to do for 2.4, if anything
[00:48:03] <cradek> bbl
[01:51:44] <morfic> is robh__ right about how G83 is implemented in emc, that G98 affects pecking retracting to initial Z instead of R?
[02:20:55] <cradek> I haven't studied that at all
[02:35:34] <cradek> seems easy enough for you to try, though (hint hint)
[02:37:07] <cradek> I'm kind of sad some of our canned cycles aren't better (like having a "first peck is different") but it's just not worth figuring out, designing the new behavior, convincing people, and implementing it
[02:37:53] <cradek> every time I do g83 r.1 q.1 z-1 I roll my eyes at the first useless peck at z0
[02:49:31] <cradek> jepler: would you release-manage me and tell me what to do about g92?
[02:50:19] <jepler> cradek: ugh
[02:50:46] <cradek> I'm not even sure how to do a "just make it an error" thing
[02:50:47] <jepler> cradek: document that the effect of G54 with rotation + G92 is undefined and move on?
[02:53:37] <cradek> what if we say we don't care what happens to the other systems with different rotations? does it become easy then?
[03:03:22] <jepler> mmmmmmm
[03:10:04] <jepler> say you have G92 in effect and change the R of the active fixture offset
[03:10:12] <jepler> can you make that work like the picture I drew?
[03:11:13] <cradek> I don't think I know what you mean
[03:12:51] <jepler> whatever we define now we won't want to change later
[03:13:07] <jepler> I think that modifying the active fixture offset has the same problems as changing fixture offsets
[03:13:46] <cradek> yes I think so too (I think you mean rotating)
[03:14:10] <jepler> yes probably
[03:15:10] <jepler> then we have to make that an error or undefined behavior too
[03:15:58] <jepler> because I think the behavior we discussed is the one that makes sense, and I don't want to enshrine as emc's behavior anything to the contrary
[03:17:35] <cradek> yeah...
[03:18:38] <cradek> "cannot use g92 in a rotated coordinate system" / "cannot change to a rotated coordinate system with g92 active"
[03:19:56] <jepler> cannot change a coordinate system to be rotated with g92 active
[03:20:01] <jepler> cannot change the current system
[03:20:44] <cradek> what's the last one?
[03:22:24] <jepler> you can't change the current system to have a rotation
[03:22:46] <cradek> oh gotcha - those two were the same error
[03:22:46] <jepler> if g92 is active
[03:31:30] <jepler> 'night
[03:31:35] <jepler> thanks for looking at this
[03:31:48] <cradek> and thanks for your help
[11:37:45] <jepler> hm. I thought I recalled seeing a report that some hostmot2-firmware BIT file wouldn't load, but I can't find it in my e-mail
[11:37:56] <jepler> does this ring a bell for anyone?
[12:48:16] <alex_joni> http://www.linuxcnc.org/component/option,com_kunena/Itemid,20/func,view/catid,38/id,2629/lang,en/#2727
[12:48:20] <alex_joni> heh, good luck
[12:54:23] <awallin_> did anyone make progress on ethernet-based IO?
[12:54:47] <awallin_> an FPGA with an ethernet-interface could be nice
[13:07:31] <CIA-2> EMC: 03micges 07v2.4_branch * rb4fe613f0567 10/src/hal/drivers/serport.comp: Update description how to disable serial port linux driver
[13:10:09] <alex_joni> awallin_: mesa is working on one, most likely to succeed imo
[13:10:25] <awallin_> sounds good.
[13:10:41] <awallin_> those 200+ pin SMD FPGA chips are not for DIY soldering anyway...
[13:10:46] <jepler> mesa's not going to do the emc software side though
[13:10:53] <jepler> at least, I'd be surprised
[13:11:12] <cradek> what is mesa working on?
[13:12:23] <awallin_> I seem to remember that previously someone was worried that depending on your ethernet card in the PC it might or might not be suitable for real-time
[13:13:00] <awallin_> there are xilinx demo-boards with both ethernet and an fpga (cost around what mesa cards cost)
[13:14:15] <jepler> you need realtime network drivers for your particular nic, and you need to find some way to make hal's and realtime networking's timing requirements be in harmony
[13:15:50] <micges_work1> it's not easy imo
[13:17:07] <alex_joni> cradek: pcw said he's working (albeit slowly) on a card like the 7i43 but with network connection instead of usb/parport
[13:17:57] <alex_joni> easiest imo would be to use EtherCAT, which has opensource masters (RT part on the PC), but needs special chips or fpga licenses on the client side
[13:44:36] <cradek> now that we've seen how good it can be (with mesa) I can't imagine going to a setup with weird licenses or closed firmwares
[13:47:37] <jepler> if you wanted a non-mesa smart I/O board hostmot2 would still be a good starting point too
[13:53:37] <jepler> (if it's targeted to an fpga anyway)
[14:03:27] <cradek> jepler: like you, I'm not sure about the last diff in
http://git.linuxcnc.org/gitweb?p=emc2.git;a=commitdiff;h=91e4cd9
[14:03:38] <cradek> darn, just missed him
[14:04:27] <cradek> hm maybe it is a redundant check though
[14:04:32] <cradek> (I can't run emc right now)
[14:08:31] <jepler> READ => G43.1 X1 I1
[14:08:31] <jepler> I word with no G2, G3, G5, G5.1, G10, G76, or G87 to use it
[14:08:57] <cradek> ok, good
[14:09:47] <cradek> wonder what g87 is
[14:10:11] <cradek> and I don't think G10 uses I
[14:10:42] <cradek> oh g87 is some cycle that probably doesn't work
[14:11:17] <cradek> ok G10 does use I now (for an angle)
[14:11:23] <cradek> grr gcode
[14:11:58] <cradek> all these checks should be autogenerated from a grammar ... somehow
[14:12:42] <jepler> you realize that between the two of us, we both think all the parts of emc we haven't personally written should be rewritten to be totally different
[14:13:13] <jepler> (that's not true; I didn't write hal but I think it's just about perfect)
[14:13:57] <cradek> other than that, you might be right (sadly)
[14:14:21] <cradek> much of it is hard to love
[14:20:55] <aystarik> cradek, jepler: hi
[14:21:03] <jepler> hi aystarik
[14:21:36] <aystarik> why don't rewrite if you want to?
[14:22:34] <aystarik> waste of time?
[14:22:44] <cradek> don't mistake "thinking it should be rewritten" with "I want to rewrite it"
[14:23:28] <aystarik> ah, ok... :)
[14:23:33] <cradek> also yeah, no point rewriting things that will work just the same way again only after long effort fixing the all bugs that were introduced in the rewrite
[14:23:53] <cradek> that's a mistake made only by very inexperienced programmers :-)
[14:24:04] <jepler> hey, I've made that mistake
[14:24:10] <cradek> ... like jepler
[14:24:17] <cradek> ... and me
[14:25:40] <jepler> the real payoff of a from-scratch interpreter is likely to be small compared to the time taken to correct newly written bugs or write features that were overlooked at the time of the rewrite
[14:27:17] <aystarik> may be think first then? like, make design proposal, compare pros and cons.. etc?
[14:28:11] <cradek> your conclusion that this effect is caused by not thinking first is incorrect
[14:28:18] <aystarik> state the goal of rewrite?
[14:29:06] <aystarik> cradek, no... I mean design first, start write code second...
[14:29:53] <jepler> My personal and professional programming experience hasn't yet convinced me that a design document is a silver bullet.
[14:30:01] <jepler> they're inevitably way too vague
[14:30:20] <jepler> (or else they're so big that they take as much time to write as the software; are as big as the software; and are as buggy as real software is)
[14:30:46] <aystarik> right, but with them you see the forest behind the trees :)
[14:30:50] <cradek> a good design may help you write well-designed code but cannot help you write bugfree code
[14:31:13] <cradek> stability and bugfree code can come only with time
[14:32:55] <cradek> heh, so I guess the easiest code to justify replacing is the code that is currently BOTH badly designed and buggy
[14:32:58] <jepler> anyway, I don't care to design OR write a new interpreter
[14:33:12] <jepler> it actually works well in practice for my part programs
[14:33:49] <cradek> yes the current interpreter is quite stable and works very well
[14:34:57] <cradek> it is a little hard to change, since you have to think of every error condition and forbid them all. that's the frustration that caused me to start complaining today. a different design could maybe fix that.
[14:36:05] <cradek> but aside from (like jeff) not wanting to do the rewrite, I'm not willing to give up the stability we have - it would be crazy.
[14:36:44] <jepler> I'd rather enable pluggable interpreters (in a better way than canterp/milltaskcanon which involved making a copy of task and editing it :-/) so that you can start a new interpreter for a new gcode dialect without giving up the old
[14:37:01] <jepler> (or some non-gcode language even)
[14:37:20] <cradek> that definitely sounds cool
[14:37:29] <aystarik> I was thinking aboit it lately too.
[14:37:55] <aystarik> it appears siemens has many non g-code extensions.
[14:38:39] <aystarik> btw, is it possible to write G01 X000 y000 : G01 U000 W000 ?
[14:39:22] <aystarik> like two synchronized moves for independent axis?
[14:47:22] <jepler> no. emc always moves all axes in synchronization
[14:50:27] <aystarik> g02 x0 y0 : g02 u0 w0? -- this kind of code is used for wire cutters and 4x edm...
[14:51:25] <jepler> you can write G1 X Y U W just fine
[14:51:33] <jepler> you can't do arcs in UW though
[14:52:55] <aystarik> ok
[14:54:12] <jepler> so G2 X Y I J U W is an arc in XY and a line in UW
[14:56:15] <aystarik> yes, I know that much :)
[14:56:48] <aystarik> ':' -- that puzzled me :)
[14:56:50] <jepler> UW arcs are an example of something that's not just an "interpreter" issue; it would affect all layers from interpreter to motion planner
[14:58:07] <aystarik> yes, as I understand currently only XYZ is fully featured, XY more so :)
[15:05:57] <awallin_> pcw_home: we discussed an ethernet-based fpga I/O board earlier? were you working on one?
[15:08:04] <pcw_home> We have a new FPGA card with Ethercat (7I62) but it will be a while before it does anything useful
[15:08:06] <pcw_home> We used the EC1100 ASIC. Our intentions are to run HM2 on it (with a interface processor)
[15:08:07] <pcw_home> If we get real ambitious we may try to implement COE, to advertise the HM2 hardware as CAN
[15:15:09] <pcw_home> The great thing about Ethercat is that if EMC full supported it you wouldn't any interface cards at all. Oh wait....
[15:16:18] <pcw_home> (wouldn't need)
[15:22:07] <pcw_home> By using the ASIC we have no proprietary IP in the FPGA so the FPGA source remains GPL-able
[15:33:26] <awallin_> but not all hobby servo-drives have ethercat...
[15:35:46] <awallin_> pcw_home: do you have a link to the ASIC-chip? is it something for the DIYer ?
[15:35:54] <aystarik> as I understand, you will have PC -(ethernet)-> EtherCAT board with HM2 FPGA - (digital + analog I/O) -> servo drives, etc
[15:36:14] <awallin_> aystarik: yes, that sounds right
[15:38:42] <awallin_> searching for "EC1100" doesn't give em anything useful...
[15:38:45] <aystarik> it looks like there are some license issues with EtherCAT :
http://ethercatmaster.berlios.de/
[15:42:27] <awallin_> hm, there are PIC processors with ethernet also...
[15:46:12] <pcw_home> The chip is a little problematic for a DIYer (.8 pitch mm BGA)
[15:48:10] <awallin_> PIC with ethernet:
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en545713
[15:48:25] <awallin_> I wonder if it would be possible to read/write every 1ms to that?
[15:53:35] <pcw_home> Probably on a dedicated link, but what protocol to use?
[15:53:37] <pcw_home> (and the chip is ET1100 sorry)
[15:57:24] <awallin_> or this:
http://www.ethernut.de/en/index.html
[15:57:44] <awallin_> not sure about the protocol... (something that would detect realtime delays)
[15:59:56] <aystarik> there is a smaller ET1200 device, which is more DIY-friendly :)
[16:07:30] <pcw_home> I think we didn't use the 1200 because it only has one MII (and hence Ethernet) interface (we wanted 2 for daisy chaining)
[16:10:48] <aystarik> may be something smaller like 7i43 is better with ET1200?
[16:13:46] <pcw_home> Possibly, the 7I62 has 96 I/O so its twice as many I/O and we wanted the two MIIs for redundency
[16:14:17] <pcw_home> (and simple daisy chaining)
[16:17:28] <pcw_home> The interesting thing about the Beckhoff modules is even something as simple as a 4 output module is a Ethercat device
[16:17:29] <pcw_home> with probably a ET1200 inside, but using their local (non Ethernet physical layer) transport
[16:34:49] <Lerman_> Lerman_ is now known as Lerman
[19:16:49] <alex_joni> pcw_home: wow, that sounds very cool
[19:25:19] <awallin> fpga on ethercat bus?
[19:29:45] <aystarik> why not use rtnet?
[19:43:01] <alex_joni> aystarik: that works, but you need to do a protocol
[19:43:10] <alex_joni> rtnet iirc exposes some udp or raw
[19:43:23] <aystarik> ip/udp
[19:44:06] <alex_joni> well.. udp doesn't have any safety built in, so the protocol would need to take care of that
[19:44:15] <alex_joni> and you need to implement it on the client side aswell
[19:45:43] <aystarik> do we have any protocol for 7i43 talking over parallel port?
[19:46:08] <alex_joni> epp and writing to some register map
[19:46:23] <alex_joni> I think, but I don't know the specifics too well
[19:46:54] <aystarik> with rtnet you can do the same -- write 1400 bytes/read 1400 bytes.
[19:47:21] <alex_joni> aystarik: I'm not saying rtnet can't be used
[19:47:44] <alex_joni> surely it's a doable thing.. just someone needs to do it
[19:48:04] <aystarik> ethercat seems to be closed to non-members
[19:48:07] <alex_joni> pcw_home: how much for the 7i62 ?
[19:48:28] <alex_joni> aystarik: yes, but you can use it as-is.. no need to go into details
[19:48:46] <alex_joni> or care about protocol, etc
[19:49:02] <aystarik> linux stack is not awailable yet, as I understand.
[19:49:19] <alex_joni> there are 2 ethercat master implementations that I know
[19:49:24] <alex_joni> both work with RTAI
[19:49:34] <aystarik> links?
[19:50:48] <alex_joni> http://ethercatmaster.berlios.de/ <- with licensing issues
[19:50:55] <alex_joni> and
http://www.etherlab.org/en/ethercat/index.php
[19:53:00] <aystarik> http://www.etherlab.org/en/ethercat/hardware.php -- kind of strugling...
[19:55:51] <aystarik> 8139too is harder to find than parallel port...
[19:56:07] <aystarik> don't see a benefit
[19:58:46] <alex_joni> hmmm.. 8139 is quite common around here
[19:59:06] <alex_joni> I think I have at least 10-12 stations at work with it
[19:59:24] <alex_joni> otoh, the rtnet part isn't exactly a lot better
[20:00:01] <alex_joni> http://www.rtnet.org/doc.html
[20:01:28] <aystarik> rt-firewire is interesting :)
[20:01:59] <cradek> I just bought some new e1000 boards - they are dirt cheap
[20:04:41] <aystarik> notebooks or netbooks are quite interesting, and they might have firewire
[20:04:48] <alex_joni> I'm sure an ethercat board won't replace a parport solution any time soon
[20:05:02] <aystarik> yes... :(
[20:05:19] <alex_joni> but it doesn't need to..
[20:06:53] <aystarik> parallel ports are going a way of dodo...
[20:07:23] <cradek> yes I've been hearing that for ten years
[20:07:28] <skunkworks_> heh
[20:07:45] <cradek> meanwhile, I don't own a single firewire device or machine that has firewire on it - I looked.
[20:07:57] <alex_joni> the laptop I bought last year still has a serial port on it
[20:08:14] <alex_joni> parport through the docking station..
[20:08:32] <cradek> I'm much more worried about bios problems that make realtime bad than I am about hardware interfaces
[20:08:39] <cradek> we have plenty of hardware interfaces to choose from
[20:10:02] <micges> yes it's getting worse every new motherboard
[20:10:11] <aystarik> you mean SMI?
[20:10:31] <micges> I mean realtime
[20:10:41] <alex_joni> and CPU's
[20:11:15] <alex_joni> like the Core i5 which can increase/decrease CPU frequency based on load
[20:11:18] <cradek> newegg has 21 different pci-express parport cards
[20:11:30] <alex_joni> and even overclock one core if the others are not used
[20:13:08] <aystarik> :) I was tearing my hair out trying to at least account for this i5 feature in speedstep driver :)
[20:13:40] <alex_joni> well.. good luck, they keep adding things like this
[20:14:45] <aystarik> and more so, there are several teams working against each other it seems... Like C-states make S-states kind of nonsense...
[20:15:34] <aystarik> s/S-/P-/...
[20:16:13] <aystarik> intel m/b still are able to turn every such feature off.
[20:17:24] <jepler> yes, you only have to give up your warranty
[20:17:47] <jepler> I dunno about their desktop processors, but it's quite clear that intel notebook processors don't remain in the safe thermal region without those features enabled
[20:21:40] <aystarik> there are always T-states on guard... And thermal shutdown
[20:32:33] <jepler> that'll be great in the middle of a machining operation :-/
[20:36:56] <alex_joni> rigid tapping with interruptions anyone?
[20:46:46] <jepler> small wonder everyone wants to mill with the PC involved as little as possible
[20:58:16] <PCW> alex_joni: 7I62 will be around $250 to $300 (with x9 spartan 6 part (x16 and X25 available for more $))
[21:09:53] <alex_joni> PCW: thanks
[21:10:21] <alex_joni> so it's likely to imagine HM2 running on it, with stepgens and whatnot
[21:10:33] <PCW> Yep
[21:11:00] <alex_joni> cool
[21:12:09] <PCW> Sort of a Ethercat -> anythingIO bridge
[21:13:50] <PCW> If EMC supported Ethercat drives our stuff would not even be needed for high end systems
[21:22:41] <alex_joni> PCW: I've seen 1-2 emc2 machines with ethercat devices on them
[21:22:45] <alex_joni> but mostly i/o
[21:22:51] <alex_joni> modules from beckhoff
[21:53:33] <alex_joni> good night all
[22:40:51] <PCW_> PCW_ is now known as PCW