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