Back
[00:38:18] <r00t4rd3d> looking for your girl?
[02:39:01] <Loetmichel> mornin'
[03:09:27] <DJ9DJ> moin
[04:36:25] <markvandenborre> I've been in touch with a cnc vendor
[04:36:52] <markvandenborre> and he says his machine has the el cheapo NCstudio DSP 0501 controller
[04:37:15] <markvandenborre> I have no idea if that thing is linuxcnc compatible
[04:38:01] <markvandenborre> I see something that looks like a parallell port on it
[04:38:20] <markvandenborre> connecting to what looks like a machine controller board, also good
[04:39:10] <markvandenborre> but then there is a touchscreen remote control thingie
[04:39:40] <markvandenborre> that is connected to this controller board using a parallel cable, and it has also got a usb port on it
[04:39:59] <markvandenborre> if I read what I can gather about it correctly, that is a
[04:40:14] <markvandenborre> way to connect a usb disk or something
[04:40:48] <markvandenborre> my question is very simple: will I be able to run a machine with this controller using a linux box?
[04:41:56] <markvandenborre> an image:
http://i01.i.aliimg.com/img/pb/494/700/533/533700494_844.jpg
[04:50:45] <archivist> never seen that before no idea
[04:50:52] <markvandenborre> Loetmichel: any idea?
[04:51:23] <markvandenborre> the controller board certainly looks like it does parallell communication
[04:51:58] <archivist> yes but why buy a controller that you will not be using
[04:52:29] <markvandenborre> because I don't want to fiddle with hardware
[04:52:37] <markvandenborre> I don't mind fiddling with software
[04:52:52] <markvandenborre> and the _board_ itself would still be needed, right
[04:52:58] <markvandenborre> it's part of the package
[04:53:42] <markvandenborre> I want to minimise the customisation to the machine I'm buying as much as possible
[04:54:58] <markvandenborre> archivist: does that make sense?
[04:58:01] <archivist> it makes sense sense my comment, that remote is the controller
[04:58:17] <archivist> you want to control from linuxcnc
[04:58:59] <archivist> that thing is usb, linuxcnc does not control over usb
[04:59:18] <markvandenborre> but the board where I see the connectors for the steppers
[04:59:32] <archivist> have nothing on it
[04:59:34] <markvandenborre> does parallel communication with that remote
[04:59:37] <markvandenborre> right?
[04:59:48] <markvandenborre> or at least, that's how it looks
[05:00:16] <markvandenborre> so in my simple mind, it might be as simple as:
[05:00:35] <markvandenborre> try machine functionality with the box
[05:00:49] <markvandenborre> with the remote to validate basic hardware functionality
[05:00:58] <markvandenborre> throw away the remote
[05:01:24] <markvandenborre> connect a pc directly via parallell to the board that controls the steppers & spindle
[05:01:44] <markvandenborre> and try and use linuxcnc to run the machine
[05:02:51] <markvandenborre> or is this simplistic, and might the remote be doing talking something very exotic to the controller board instead?
[05:03:31] <markvandenborre> archivist: I hope I'm not annoying you too much with my newbie questions
[05:03:59] <archivist> how can we know from a picture, buyer beware
[05:04:20] <markvandenborre> even that is a useful suggestion
[05:04:25] <markvandenborre> thank you
[05:04:59] <archivist> your assumptions could be correct but....are they
[05:05:22] <markvandenborre> any hints on finding out? search keywords?
[05:05:31] <markvandenborre> name of a protocol?
[05:06:00] <markvandenborre> do I need to find out chips on the controller board?
[05:06:30] <markvandenborre> anything I can ask the supplier to improve my chances?
[05:11:22] <markvandenborre> or is there any controller board that can be swapped in extremely easily?
[05:13:39] <Loetmichel> MarkusBec: you dont NEED a controller board.
[05:13:49] <Loetmichel> Thats what the Computer/LPT is for
[05:13:54] <Loetmichel> grrr
[05:13:58] <Loetmichel> markvandenborre
[05:14:18] <markvandenborre> Loetmichel: I think you underestimate the part that I do understand
[05:14:44] <markvandenborre> I know the stepper control electronics can be very dumb
[05:14:46] <Loetmichel> you only neet stepper/servo drivers with step/dir and a breakoutboard for the parallel port if not integrated in the Stepper driver
[05:14:46] <markvandenborre> with linuxcnc
[05:15:17] <Loetmichel> the stepper drivers are dumb as hell, the only get two signals from the PC for each axis: step and direction
[05:15:24] <Loetmichel> servo drives the same
[05:15:49] <markvandenborre> so my question was mostly if you could say something useful about the board that is part of this package
[05:16:00] <Loetmichel> and tha parallel port does noting more or less then wiggeling with its portpins accorting to which motor should turn
[05:16:01] <markvandenborre> "controller board" is probably ascribing it too much intelligence
[05:16:25] <Loetmichel> this board seems to be containing only a breakout
[05:16:41] <markvandenborre> so in that case it would be perfect for linuxcnc, right?
[05:16:46] <Loetmichel> the intelligence is in the handpiece
[05:16:59] <markvandenborre> that's what my intuition told me
[05:17:26] <Loetmichel> which seems to have a full gcode interpreter in it, so you can send it gcode via usb, and position the maschine with the keys/display and run the gcode from the handset
[05:17:31] <markvandenborre> is there any way that the seller can confirm this "breakout board", "intelligent remote"
[05:17:45] <Loetmichel> it is more a replacement for linuxCNC and C than anything else
[05:18:00] <markvandenborre> to me, so I can be certain about being able to control the machine using linuxcnc?
[05:18:16] <Loetmichel> wothout htaqt board: yes
[05:18:25] <markvandenborre> Loetmichel: ?
[05:18:26] <Loetmichel> directly from the lpt to the stepper drtivers
[05:18:35] <Loetmichel> sorry, big fingers again
[05:18:40] <markvandenborre> :-)
[05:19:04] <markvandenborre> "wothout htaqt board: yes
[05:19:06] <markvandenborre> "
[05:19:07] <markvandenborre> ?
[05:19:15] <markvandenborre> you mean without that remote?
[05:22:06] <archivist> that remote is a pc replacement and has nothing to do with your quest for a machine
[05:22:38] <markvandenborre> archivist: I do understand that very basic bit of linuxcnc, thank you
[05:23:13] <markvandenborre> in fact, thank you both
[05:23:34] <markvandenborre> your hints have really helped me
[05:24:25] <markvandenborre> I can be fairly confident now that I can throw away the intelligent remote
[05:24:46] <markvandenborre> and use the parallel port on the dumb breakout board that is also part of the package
[05:24:54] <markvandenborre> because that was my main concern:
[05:25:17] <markvandenborre> not having to fiddle with the electronics hardware wiring
[05:25:27] <markvandenborre> changing the breakout board
[05:26:35] <archivist> I do not know why you are looking at that remote I assume you are looking at
http://www.aliexpress.com/store/product/Free-shipping-CNC-wireless-channel-for-CNC-router-cnc-engraver-CNC-Router-DSP-controller-0501-DSP/210206_595635561.html
[05:27:44] <markvandenborre> I am mentioning that because it comes as a part of the cnc machine I am considering
[05:33:28] <markvandenborre> I don't mind paying a little bit extra for the assurance that I am ending up with something that can be used immediately (if a bit crippled)
[05:33:29] <markvandenborre> and the confidence that with some work it can be used without the remote and with linuxcnc
[05:33:29] <markvandenborre> besides, it seems to be a standard part of the machine, it's not that I would save a lot by throwing that out
[07:06:08] <R2E4> .
[07:08:37] <R2E4> hi all
[07:09:50] <skunkworks> Good morning!
[07:14:03] <R2E4> Well, confirmed, need some kind of board fabrication interface to make this work with the R2E4.
[07:14:07] <ProxDem> R2E4: heya
[07:14:24] <R2E4> Everything is on edge cards in the card cage.
[07:14:49] <R2E4> hiya Prox
[07:15:14] <ProxDem> R2E4: dunno if you got my messages from last nite =)
[07:15:25] <R2E4> I am going to start looking for replacement amps to work with the 5i25 and 7i77
[07:15:38] <R2E4> What message?
[07:15:49] <R2E4> cell phone?
[07:15:59] <ProxDem> R2E4: let me retype them in pm
[07:16:17] <R2E4> ok, it is probably on my work computer.
[07:23:48] <R2E4> Anyone have any good ideas on where to start looking for new servo amps for existing bridgeport servo's and mesa boards?
[07:25:53] <skunkworks> R2E4, use the existing amps....
[07:33:17] <R2E4> Cannot, they are in a card cage, and I dont have the experience to engineer an interface for it. I dont know the syustem to be able to remove this card and that card, everything is in a card cage with edge connectors.
[07:33:53] <ProxDem> interesting
[07:34:22] <R2E4> I cannot find anyone who has attempted this, or maybe I might be able to get by with it.
[07:34:24] <ProxDem> so they al share a common communication bus then probably and power lines
[07:34:48] <R2E4> the 5 volts is coming from the bus.
[07:35:04] <ProxDem> maybe if you can find the schematics for the card cage itself you could make your own pcb that interconnects with the cage via a hand made gold finger card =P
[07:35:35] <ProxDem> R2E4: any pictures of the interface bus and the card cage?
[07:35:38] <R2E4> haha
[07:36:28] <ProxDem> long nights with an oscilloscope and good multimeter might yield you some results if a schematic isn't available...but there should be some out there
[07:36:38] <R2E4> I was talked into this route which was a mistake I think.
[07:36:56] <ProxDem> R2E4: who talked you into this?
[07:37:30] <R2E4> I'm not interested in starting to create interfaces, debug bblabla...... I'd rather spend the 1800 on new drives and encoders and be done with it.
[07:37:52] <R2E4> or however much they cost. The AMD look nice but probably expensive.
[07:38:45] <ProxDem> ahh so a complete overhaul
[07:39:59] <ProxDem> sounds like a fun project =)
[07:40:04] <R2E4> I bought the mesa cards so I am pretty much married to the linuxcnc route but its not the end opf the world if I dont.
[07:41:14] <ProxDem> the mesa cards allow for so much nicessness it would be a shame to not use them
[07:41:30] <R2E4> not really, It will take me a while, in the mean time I have to sub out some small contractsI got.
[07:41:35] <ProxDem> the fact that they offset all the pulse generation (in my case would be a plus)
[07:41:45] <ProxDem> R2E4: the subbing out part will suck for sure =(
[07:41:57] <ProxDem> as you won't have exact control of the timeline or Quality
[07:42:06] <ProxDem> and the $$ involved
[07:42:52] <ProxDem> R2E4: do the electronics/controls actualy work? could you not load your gcode directly into the machine if they work?
[07:44:52] <R2E4> there's another issue. Not sure. If I spend three weeks or more on creating something that would work, then power up, to find out the drives dont work then would have to spend for new amps anyway? That would blow.
[07:46:31] <R2E4> Thats what I am going to be up to next. But it is in really clean condition but I have noticed a battery board all corroded so not sure if this will work. I will clean that mess up and power up when I get electrician in and see. That will dictate my next move.
[07:47:27] <R2E4> encoders will be 300.00 bones, not sure about amps.
[07:49:38] <R2E4> I dont know if newer drives have any logic to handle the estops limits etc....
[07:55:08] <ProxDem> http://www.geckodrive.com/electromechanical-estop
[07:55:12] <ProxDem> that's always one way you can go
[07:56:51] <ProxDem> R2E4: sounds like you're gonna be dishing out alot of $$$ and time to get this up and running...but I think in the end run it'll be worth ever penny
[07:57:57] <ProxDem> or should I switch that to nickel as we round out now =P
[08:01:21] <ProxDem> R2E4: when you say AMD...do you mean AMC?
[08:18:09] <R2E4> yeah, AMC drives
[08:25:09] <ProxDem> R2E4: those do look nice!
[08:25:27] <ProxDem> R2E4: enjoy the snow storm! lol
[08:37:17] <cradek> R2E4: I understand why you would choose to get new amps to simplify wiring, but I don't understand why you would ever replace already-mounted already-wired sealed encoders
[08:38:24] <cradek> (if you are short on expertise and you have a powerful checkbook to compensate, perhaps hiring someone would be better than buying unneeded parts?)
[08:38:47] <cradek> I agree the first thing to do, if you have jobs waiting for it, is to power the thing up and see if it works
[08:39:06] <cradek> I did a lot of good work on my R2E3 as it came (after a few simple repairs)
[08:39:36] <cradek> even if you are going to immediately retrofit it, the first step is to power it up and see what you have to work with
[08:41:01] <R2E4> Many people are saying the 200ppr encoders need to be replaced because of the resolution. That was the reasoning behind that.
[08:41:24] <cradek> one of the tedious parts of a retrofit is the mechanical stuff: mounting this and that in the cabinets, and running wires. by replacing amps you probably make that part harder
[08:41:50] <R2E4> Hiring someone to come in and reengineer the system will cost much more than replacing the amps.
[08:41:57] <R2E4> +
[08:41:58] <cradek> those encoders are set to give you 0.0001" resolution. I question whether those opinions are based in fact or feelings
[08:42:58] <cradek> "200 feels like a low number when 1024 is common nowadays" does not mean they are wrong for the machine
[08:43:20] <R2E4> I mount electromechanical panels all the time and have been doing it for 20+ years. wiring, designing and troubleshooting. This would not be a problem for me.
[08:43:23] <cradek> just beware, is all I'm saying
[08:43:40] <R2E4> Thats good If I wont have to change the encoders.
[08:45:25] <R2E4> I would rather not change them but I see no recourse...... All the cards are in a card cage with a backplane. Something will definately have to be engioneered for this to work and I do not know enough about these devices to do it. Paying someone else will be much more expensive.
[08:45:36] <R2E4> That is my reasoning behind changing them.
[08:46:12] <R2E4> ITs not as simple as just rewiring them, we have found that out.
[08:47:28] <cradek> the backplane may very well be a single sided pcb with no crossing traces. you might be able to unsolder an edge connector and put screw connectors in or something equally simple...?
[08:47:38] <cradek> you'll know more when you get the machine I guess.
[08:48:14] <cradek> if you fire it up and find two of them are dead anyway, the decision becomes easy!
[08:49:51] <ProxDem> I think R2E4 is looking at it engineering and buisness wise...
[08:50:21] <ProxDem> buisness wise any down time = loss of income...so while some solutions are cheaper then others...they are more time consuming...and that hurts the bottom line
[08:50:48] <cradek> R2E4: pretty sure your encoders are 250, not 200:
http://timeguy.com/cradek-files//emc/bridgeport-r2e3/imag0143.jpg
[08:50:48] <ProxDem> thus why I think I understand his choice of changing stuff up...yes the initial cash drop is greater...but he'd be up and running faster with less headaches
[08:51:02] <R2E4> I have the machine
[08:51:37] <cradek> are they really 200?
[08:52:14] <cradek> brb
[08:52:15] <R2E4> No, they are 250..... I didnt remember 200 or 250.
[09:26:00] <cradek> yeah with a 0.200 screw and 2:1 pulleys that gives you 0.0001" per count. that is the native resolution of the old control.
[10:06:33] <r00t4rd3d> http://www.adafruit.com/products/565
[10:08:04] <r00t4rd3d> http://www.adafruit.com/products/691
[10:08:06] <r00t4rd3d> better
[10:08:10] <r00t4rd3d> sticker
[10:22:15] <skunkworks> enco free shipping on orders $49 or more. SPRING
[10:22:22] <cradek> woo
[10:30:55] <Jymmm> cradek: Time to order all that heavy steel now =)
[12:04:57] <Connor> skunkworks_: Yup.. He's got a motor turning!! Yay!! Not bad.. Helped walk him through everything over the phone.. using hardware I've never used...
[12:08:33] <Loetmichel> re @ home
[12:11:03] <Loetmichel> so, got car back... 989,60 eur for the repair.... i should found a car repair shop! that seems like a gold mine... :-(
[12:12:26] <micges> gee, half of total price of my car :)
[12:21:32] <Loetmichel> micges: the car is an Opel Omega. had cost me 5000 eur 2 years ago
[12:22:01] <micges> what year?
[12:22:03] <Loetmichel> and ist "pristine condition"... no rust for an OPEL from 2004 is nice
[12:22:13] <micges> ah
[12:22:23] <R2E4> I have a question, when you disconnect encoders from drives and send them into mesa cards, What do the drives do with no encoider inputs?
[12:22:32] <R2E4> Sure they wont be very happy.
[12:22:54] <ProxDem> eek
[12:23:04] <micges> why would you do that?
[12:23:12] <ProxDem> AFAIK they should rely on the encoders to give them positions
[12:23:43] <Loetmichel> R2E4: why do that? simply feed the Encoders parallel to the servo drives AND the mesa...
[12:24:03] <pcw_home> your current drive dont have any direct encoder connections
[12:24:08] <ProxDem> Servos need that "feedback loop" to work....steppers on the other hand know that worse comes to worse they've missed a step....hard to say what the controller would do...either it would simply turn none stop waiting for signal...or maybe it knows after X amount of time it should've travelled the distance and stops
[12:24:51] <Loetmichel> and says "follow error" in some way
[12:24:57] <Loetmichel> @ ProxDem
[12:25:11] <ProxDem> Loetmichel: follow error?
[12:25:27] <pcw_home> your current drives are quite simple the just have a +-10V analog input, a tachometer feedback input, and an enable input
[12:25:29] <ProxDem> interesting Loetmichel
[12:25:35] <R2E4> To close the loop with Linuxcnc, it needs the encoders wired into the mesa boards.
[12:26:03] <ProxDem> I think wiring them in parallel might be an option if the input isn't 2 high for the mesa boards
[12:26:10] <R2E4> pcw_home: yes i know, but I am looking into purchasing new drives as another option.
[12:26:46] <pcw_home> Are all the cards in one backplane?
[12:26:55] <R2E4> yes.
[12:27:21] <R2E4> uh...... I think. Will have to check but am pretty sure.
[12:27:39] <Loetmichel> ProxDem: most servo dirvers i know have a way of telling the PC/CNC that the distanve betreeen "should be there" and "i am here" has grown larger than the predefined value
[12:27:58] <pcw_home> the actual number of signal to the drives is small however (and there are a lot of blue wirea flying around)
[12:28:07] <ProxDem> Loetmichel: so my 2nd guess was actually sorta correct then?
[12:28:19] <Loetmichel> ProxDem: yes
[12:29:05] <ProxDem> Loetmichel: nice I was reading on what you said
http://digital.ni.com/public.nsf/allkb/899AE29CB4E3578B8625709D0070A725
[12:29:10] <ProxDem> very interesting read thanks for the info =)
[12:29:24] <pcw_home> Normally for LinuxCNC servos, linuxCNC closes the loop so the error (following error) is monitored by linuxCNC
[12:30:52] <Loetmichel> pcw_home: when the driver has connetions for an encoder i would bet my money on a closed loop driver that gets only step/dir from the CNC
[12:31:10] <Loetmichel> so the loop is closed in the driver, no need to do that in LinuxCNC
[12:31:21] <Loetmichel> but thats just a rough guess
[12:31:29] <ProxDem> makes sense
[12:31:29] <R2E4> pcw_home: i don't know what i would need to satisfy the drives. If I am looking at it properly, the FMDC handled most of the processing and logic. This would need to be done by linuxcnc
[12:32:29] <Loetmichel> R2E4: is the servos/drives combination from THIS machine?
[12:32:58] <Loetmichel> or are you throwing some spare parts together?
[12:33:01] <pcw_home> Like I said the drives are quite simple (they take a analog velocity command) probably no more than 4-6 control signals needed
[12:33:05] <R2E4> boss 8 or 9, dont know which
[12:33:20] <Loetmichel> (because closed loop servo drives have to be calibrated (PID))
[12:33:39] <R2E4> http://www.irmtl.com/LinuxCNC/R2E4/r2e4-3.jpg
[12:34:11] <Loetmichel> ah, i see, classic +-10V velocity signal i presume?
[12:34:24] <R2E4> yes
[12:34:34] <pcw_home> Loetmichel the controller gets high level commands not step/dir so is not useful
[12:34:59] <Loetmichel> DC servos or AC servos?
[12:35:07] <pcw_home> DC
[12:35:10] <R2E4> DC
[12:35:43] <Loetmichel> *SHI**
[12:35:46] <pcw_home> so if the backplanes are separate it should be easy to wire
[12:36:18] <Loetmichel> but should be interfeceable with linuxCNC
[12:36:41] <R2E4> I don't think they are. One cage with pcb backplane across the back
[12:36:42] <Loetmichel> you are right that the mesa card needs the encoders.
[12:37:32] <R2E4> I was only referencing if I went with new servo drives re:
http://www.a-m-c.com/download/datasheet/dpralte-015b200.pdf
[12:37:47] <Loetmichel> but there is no way from my side to know if the driver NEED the encoders or if the have a "dumb mode, just amplify the +-10V signal", because i dont know that machine.
[12:38:20] <pcw_home> The drives DO NOT need the encoders
[12:38:28] <R2E4> The drivers on that machine does not need the encoders. The encoders went into a processor board that fed the drivers
[12:38:39] <R2E4> drives
[12:39:02] <ProxDem> well then if you aren't using the onboard equipment your idea of rerouting the encoders to the mesa board makes sense
[12:39:19] <pcw_home> right because the FMDC card ran the PID loop, now LInuxCNC will
[12:39:38] <R2E4> Theres two different scenarios, one purchase new drives two try and make the existing ones work.
[12:39:55] <pcw_home> Do you have a backplane schematic?
[12:40:31] <R2E4> I tried looking last night but haven't found it yet. I have about 8 books that came with the machine....hehe.
[12:40:59] <R2E4> looking at the schematics, there are two signals I don';t know what to do with coming from FMDC
[12:41:47] <pcw_home> drivers will typically have analog in (differential if you are lucky) enable in and fault out
[12:42:11] <R2E4> A fault latch, and a pair of wires parralell with tach input into drives
[12:43:04] <R2E4> question remains how to enable them which was done via fmdc before, and will the drives be happy without the latch alarm input
[12:43:20] <R2E4> maybe that a latch fault out?
[12:43:25] <pcw_home> the tach to FMDC can go, the fault latch needs to be dealt with
[12:44:22] <R2E4> mesa boards have a fault input? Don't know what signalis coming out of the drives but can the mesa board deal with it?
[12:44:48] <skunkworks_> Connor, over the phone? holy crap
[12:44:52] <skunkworks_> that is impressive!
[12:44:57] <Connor> Yes. Over the phone. :)
[12:45:07] <pcw_home> The drive specs would be the most valuable at this point so the enable and fault signal levels and polarity can be determined
[12:45:32] <R2E4> i can dig that up I think
[12:45:51] <Connor> I mean.. I had Pncconf on my machine that I use for simulation.. but, that only got me so far...
[12:46:19] <Connor> and it was putting the driver into Speed mode that was the issue.
[12:46:34] <R2E4> pcw_home: you have a way of making it seem simple.
[12:46:50] <pcw_home> There may possible need to be some level shifting depending on what those signals are like
[12:46:56] <R2E4> up until the point I leave the screen....
[12:47:50] <R2E4> I have the maintenance manual with me at work. Let me look in and see if I can get some data out of that.
[12:48:00] <pcw_home> lots of people have retrofitted similar hardware, its not really rocket science....
[12:49:33] <pcw_home> sure be nice if the controller was on a different backplane than the drives though
[12:50:09] <skunkworks_> Connor, what did he end up doing to change the mode of the drives?
[12:50:44] <Connor> Go through the menu on the front.. and hold the enter key down for around 2-4 seconds on the proper menu.. he just wasn't holding it long enough..
[12:50:52] <Connor> of the driver that is.
[12:51:02] <skunkworks_> ah - neat
[12:51:31] <skunkworks_> He should not try to tune until it is hooked to the table.. It is hard to tune with no load.
[12:51:45] <skunkworks_> or atleast not try too hard.
[12:51:56] <Connor> Oh yea. He wants to get the e-stop and limits going first before that..
[12:52:05] <skunkworks_> Good!
[12:52:09] <Connor> I have NO exp in tuning...
[12:52:21] <skunkworks_> I only have very little.
[12:52:27] <Connor> I don't understand PID at all..
[12:52:33] <Connor> and the SSF values..
[12:52:35] <Connor> etc..
[12:53:13] <pcw_home> JT has a nice tutorial for velocity mode drives
[12:53:16] <skunkworks_> I was trying to find - I thought peter had explained volocity mode tuning in one of the list emails.
[12:53:22] <skunkworks_> oh - maybe it is JT
[12:53:44] <R2E4> +15vdc fault latch
[12:54:00] <R2E4> into a DLI board that feeds the fmdc
[12:54:12] <pcw_home> the trick with velocity mode is the heavy lifting is done by FF1
[12:55:03] <Connor> okay. Someone can find the link for the video, that would be great.
[12:55:23] <Connor> His Drivers support Velocity(Speed), Step/Dir, and Torque.
[12:55:58] <skunkworks_> imo velocity is the easiest to tune...
[12:56:02] <Connor> and, combinations of some of those too..
[12:56:12] <pcw_home> http://gnipsel.com/linuxcnc/tuning/servo.html
[12:56:19] <Connor> step/dir is a joke for this machine.. he wanted closed loop all the way.
[12:56:42] <skunkworks_> I am glad he wasn't swayed by the step/dir people...
[12:56:56] <skunkworks_> It is Closed loop!!! (at the drive)
[12:57:00] <skunkworks_> ;)
[12:57:06] <Connor> Yea. He knew better.
[12:57:22] <Connor> I call those Hybrid Closed Loops..
[12:58:07] <skunkworks_> Connor, glad he has someone close farmilar with linuxcnc.
[12:58:15] <pcw_home> The velocity loop is still closed at the drive but LinuxCNC closes the position loop
[12:58:51] <Connor> pcw_home: Yea. It's better than step/dir mode..
[12:59:21] <pcw_home> For torque mode you typically need higher servo thread rates
[13:00:07] <Connor> skunkworks_: Yea. I know enough about LinuxCNC to be dangerous. I know Linux pretty good though..
[13:00:12] <pcw_home> (since the velocity part of the loop is closed by linuxCNC with a torque mode drive)
[13:00:27] <Connor> pcw_home: So, what's better, velocity, step/dir, or torque? and can the 7i77 do torque ?
[13:01:15] <pcw_home> better is tough to say since there are multiple dimensions
[13:02:49] <pcw_home> typically for larger systems velocity mode is good
[13:02:51] <pcw_home> torque mode is a bit tougher to tune and needs faster hardware
[13:02:53] <pcw_home> The 7I77 can do torque, it really does no matter what the command is
[13:03:26] <R2E4> 15vdc fault signal. I can energize a relay and privde dry contact to mesa boards. This be ok?
[13:03:28] <Connor> okay. I wasn't sure how torque was interfaced if it still used the 0-10v outputs or what.
[13:04:34] <IchGuckLive> hi all B)
[13:04:42] <pcw_home> torque mode has some advantages (homing to mechanical stops) torque limits during homing
[13:04:44] <pcw_home> force/energy measurement (for tooling condition) etc
[13:05:00] <R2E4> it is sending tach data to the fmdc. hehe, i thought it was the other way around
[13:05:11] <pcw_home> yes torque is +-10V
[13:05:59] <pcw_home> probably tach voltage goes to both the FPDC and the drives
[13:06:10] <R2E4> yes
[13:06:50] <R2E4> axis motion and spindle being enabled via relay CR1
[13:07:14] <IchGuckLive> @ all (some) B) can someone check if sound i ok on the new Vid uploaded to youtube please THANKS .
http://www.youtube.com/watch?v=LUQkPDJoRdc
[13:07:48] <R2E4> UDIO IS FINE
[13:07:53] <R2E4> audio is fine
[13:07:58] <IchGuckLive> Thanks
[13:11:51] <R2E4> Is one of the functions of the E-stop to disable the drives?
[13:12:02] <R2E4> and spindle
[13:13:09] <cpresser_> R2E4: yes, it is. i prefer to wire that in hardware
[13:14:06] <cpresser_> estop should not depend on linuxcnc running (my opinion)
[13:14:13] <R2E4> There is a control module I can apply power to that will do this. I will lose the logic and will have to fill in the blanks...
[13:14:42] <R2E4> The controller usually handles the logic for it no?
[13:15:03] <R2E4> and LinuxCNC is the controller in this scenario.
[13:16:25] <cpresser_> there is more than one way to implement estop.
[13:16:28] <pcw_home> Normally the logic for ESTOP is just some relays/contactors with perhaps
[13:16:30] <pcw_home> an enable signal from the controller and status back to the controller
[13:17:08] <cpresser_> i prefer to wire my estop-button and the estop signal from the controller with a logical-or. the outpur from the OR is then connected to the enable-signal of the drives
[13:17:55] <pcw_home> (and of course big red latching mushroom switch)
[13:19:41] <R2E4> The bridgeport does it through relays and dynamic braking relays for the xyz.
[13:19:56] <pcw_home> Right
[13:20:54] <pcw_home> so that logic should be able to remain pretty much untouched (if you keep your existing drives)
[13:21:23] <R2E4> but the fmdc controller receives the estop and energizes the relays via flipflop/autocoupler whatever, but the controller is involved in the R2E4
[13:23:21] <pcw_home> And that feature will now be done by LinuxCNC
[13:23:45] <R2E4> OK......cool
[13:30:43] <R2E4> There is a current analog output out of the drive going to the fmdc.
[13:31:03] <R2E4> nope, not going to the fmdc.......
[13:35:51] <Jymmm> Ok, is it a good idea to go refill BOTH the propane tanks AND the Nitrogen tank in the same car??? hehehehehehehe
[13:36:43] <IchGuckLive> Jymmm: and fly to the moon O.O
[13:36:53] <Jymmm> IchGuckLive: Pretty much =)
[13:36:56] <skunkworks_> well - nitrogen is inert.... SO they cancel out?
[13:37:10] <Jymmm> skunkworks_: Nitrogen tank is 2000 PSI =)
[13:37:30] <Jymmm> skunkworks_: in other words, a rocket in a bottle =)
[13:45:49] <Connor> My E-Stop trips a relay, which kills power to the charge-pump and the SSR for the spindle.
[13:47:00] <jdh> you can get 6kpsi n2 bottles
[13:48:23] <Connor> jdh: for what purpose ? :)
[13:48:45] <skunkworks_> diving?
[13:48:49] <jdh> increased volume, easier to transfill, etc.
[13:49:06] <jdh> not much need for plain N2 in diving. Plenty of it in normal air
[13:49:24] <skunkworks_> heh
[13:49:32] <jdh> I think some aircraft parts use it? landing gear struts or something?
[13:58:22] <toastydeath> anything that undergoes thermal cycling
[13:58:38] <toastydeath> tires get n2 fill as well as the shocks, yeah.
[14:01:31] <andypugh> I filled my dirt-bike shock with Argon when I rebuilt it. I had argon, and it seemed likely to be at least as good as dry nitrogen.
[14:02:11] <toastydeath> sounds reasonable
[14:02:37] <jdh> argon has a reputation as a 'dirty' gas in diving circles. Seems silly and I've never seen any real reason it would be less filtered/dry than any other compressed gas.
[14:02:50] <toastydeath> i'm pretty sure there's a mass term in the damping equations
[14:03:10] <toastydeath> but I don't think it makes a huge difference for gas shocks
[14:03:22] <jdh> people use it for dry-suit inflation. Supposed to have lower thermal transfer than air/etc.
[14:10:28] <cpresser_> jdh: i dont quite understand that. arent all gases supposed to behave the same (for temperature, pressure, volume)
[14:12:51] <jdh> dunno about that... heat transfer is definitely not the same.
[14:13:18] <jdh> helium is much more thermally conductive than air or argon
[14:13:21] <skunkworks_> hydrogen has one of the best heat transfer ability...
[14:13:41] <jdh> hydrogen has its own issues though
[14:13:48] <ProxDem> helium is running out
[14:13:49] <skunkworks_> boom?
[14:13:55] <ProxDem> soon we won't have no more!
[14:14:07] <mrsun> that will be fixed with just a small supernova
[14:14:17] <mrsun> novae
[14:14:19] <ProxDem> bye bye liquid helium for overclockers...they'll have to stick with liquid nitrogen
[14:14:43] <jdh> who overclocks with either of those?
[14:15:22] <jdh> we have liquid N2 for vacuum cold traps, and liquid He for magnet cooling
[14:20:59] <ProxDem> jdh: love what you have left of liquid HE
[14:21:17] <ProxDem> jdh: all the top overclockers use either of those
[14:21:38] <ProxDem> that's when you outgrow phase change cooling....which comes after you've outgrown liquid cooling
[14:39:13] <L84Supper> hah, the helium isn't runing out, it's just mixing in with the other gases in the atmosphere
[14:45:27] <ProxDem> the manufacturers are slow at producing it
[14:45:44] <ProxDem> it was sarcastic
[14:45:47] <ProxDem> http://www.cnn.com/2013/03/02/opinion/flynn-balloon-helium
[15:06:39] <Connor> So, when tuning a servo.. Do you have to make a change then reload linux CNC every single time? Is there a easy way?
[15:06:47] <skunkworks_> no
[15:07:04] <skunkworks_> Yes there is an easy way
[15:07:06] <Connor> no reloading linuxcnc or no on easy way
[15:07:12] <skunkworks_> ;)
[15:07:44] <combscs> #emc forwards to #linuxcnc?
[15:08:09] <skunkworks_> Connor, Calibration - Starts a PID tuning assistant, which is mainly for servo systems. Some things can be changed on a stepper system.
[15:08:20] <skunkworks_> under the machine menu in axis
[15:08:24] <skunkworks_> 'machine'
[15:10:57] <skunkworks_> combscs, this is for linuxcnc - used to be called EMC (enhanced machine control)
[15:11:17] <combscs> aah
[15:51:42] <L84Supper> "Cannot join #emc (Channel is invite only)."
[15:52:02] <DJ9DJ> re
[16:02:11] <andypugh> Well, I haven't seen that before:
https://plus.google.com/photos/108164504656404380542/albums/5747722155741347649/5857158998686911074?banner=pwa
[16:03:48] <andypugh> L84Supper: I think Helium escapes to outer space (like Hydrogen does) so it is running out.
[16:03:57] <andypugh> The source (bizarrely) is mining.
[16:06:53] <andypugh> When there was a bang and a blue flash, followed by the lights going out and a funny smell I I was rather expecting the sauce to be an exploding capacitor, not a power resistor.
[16:07:30] <andypugh> (Confused, I am sure I _twice_ types "source")
[16:08:46] <andypugh> It looks like the underlying cause was a short in the bridge rectifier.
[16:11:00] <eykreinecke1> my tb6560 don´t work. Zwei von drei Stepper fiepen, doch fahren nich an, wenn ich von Hand die Pfeiltasten drück.
[16:14:08] <andypugh> Do they move at all? If they move onse step every time you change direction then it means the step and direction signals are swapped.
[16:18:46] <DaViruz> exploding capacitors can lead to sauce.
[16:21:57] <andypugh> It's kind of interesting how the ceramic core has split itself into approximately equally-sized lumps
[16:23:12] <andypugh> Do you think I can put it back together?
[16:23:21] <ProxDem> yeah
[16:23:28] <ProxDem> nice brown electrolytic mixture
[16:23:30] <ProxDem> it's nice =P
[16:23:48] <andypugh> No electrolyte, it's a resistor.
[16:23:49] <ProxDem> as for ceramics it's just a puff and bits everywhere
[16:24:00] <ProxDem> < DaViruz> exploding capacitors can lead to sauce. <-- that's what I was refering 2
[16:24:27] <ProxDem> andypugh: but yet exploding power resistors in ceramic casings are also fun =P
[16:24:45] <ProxDem> but when they are in an aluminum heatsink they tend to just crack
[16:24:56] <andypugh> This was an aluminium cased one. It dented the lid of the case.
[16:25:14] <andypugh> Did you see the picture?
[16:28:46] <ProxDem> nah i didn't
[16:28:54] <ProxDem> url?
[16:29:33] <ProxDem> nvm saw it
[16:30:13] <ProxDem> nice
[16:31:45] <andypugh> i am glad it was the resistor (£5) and not the cap (£75)
[16:34:58] <ProxDem> heuheuhe
[16:38:25] <skunkworks> andypugh: what is that - braking resistor?
[16:38:28] <R2E4_> pcw_home: I am getting closer.
[16:38:51] <R2E4_> The board on the far right is an interface board between the drives and the fmdc.
[16:41:04] <ProxDem> glad to hear you're getting farther in your quest R2E4_ =)
[16:41:12] <andypugh> skunkworks: That is a soft-start resistor. It's job is to limit the inrush current so that the breakers don't pop. After 10 seconds a timer shorts it out. However, I had removed the shorting relay in case that was the problem. In theory it should have charged the cap normally, and then the current flow would have gone to zero. In practice I think that the caps were being continuously discharged by the shorted rectifier,
[16:41:12] <andypugh> there was a steady-state current of, well, lots.
[16:42:47] <andypugh> It seems that that resistor struggles with a steady-state 1.1kW. It is a 100W device, running more than that very, very, briefly in normal use.
[16:44:27] <skunkworks> yeck
[16:45:43] <tjb1> Is there a way to have HAL read a value from g-code?
[16:45:55] <R2E4_> I have access to the signal going to the fmdc but dont know if I should access them after the interface board or directly at the backplane connector.
[16:48:27] <andypugh> tjb1: Yes, there are the G-code analogue outputs.
[17:10:36] <DJ9DJ> gn8
[17:47:52] <Tom_itx> andypugh what did the power resistor do?
[17:48:15] <Tom_itx> as it's intended purpose...
[17:48:17] <Valen> I had something to tell you andypugh
[17:48:20] <Valen> now i forget
[17:48:57] <Valen> also, why does an american 400HP feel slower than a ferari 400HP, "this car brought to you by the makers of the 3 speed automatic"
[17:49:43] <andypugh> Tom_itx: It reduces the inrush current when the smoothing capacitors are first charged.
[17:49:49] <Tom_itx> nevermind.. finished cathing up...
[17:50:38] <Tom_itx> did it screw up the caps too?
[17:50:47] <andypugh> I don't think so.
[17:50:56] <Tom_itx> i bet it didn't do them any good
[17:51:42] <andypugh> The caps are powered through that resistor, so they probably didn't even notice.
[17:53:34] <Tom_itx> what's the blue thing on the pcb?
[17:55:33] <andypugh> It's a little 12V transformer to power the 555 timer circuit.
[17:59:52] <skunkworks> andypugh: inverting the input and output scale doesn't fix it?
[18:00:42] <andypugh> skunkworks: It's not that simple, it seems.
[18:01:04] <skunkworks> huh
[18:01:06] <L84Supper> why do Ferrari's only have torque when you wind them up over 5k rpm?
[18:01:29] <Tom_itx> probably small pistons with short stroke crank
[18:01:38] <andypugh> L84Supper: Ask again when you understand what torque means :-)
[18:01:39] <skunkworks> because they are small displacement - high reving - over-square engines
[18:02:12] <Valen> generally that would imply a lack of torque
[18:02:12] <L84Supper> washing machine powered cars
[18:02:18] <andypugh> skunkworks: I am not sure I have an output scale.
[18:02:20] <Valen> lots of power but still
[18:02:40] <andypugh> I need to check more carefully.
[18:03:43] <Valen> thats what I like about my falcon, peak torque is around 2200 RPM i think
[18:03:59] <skunkworks> andypugh: In a normal setup - I think that it is just the pwm scale...
[18:04:25] <skunkworks> so - input scale is encoder scaling - output scale is pwm scaling
[18:04:55] <andypugh> I can't remember if the 7i49 uses PWM for output.
[18:05:01] <skunkworks> heh
[18:05:09] <Valen> 3150RPM peak torque, normal driving is ~2000 RPM, instant powerband ;->
[18:06:31] <Tom_itx> i wonder if i should even fool with this washer motor since it only does around 1600 rpm
[18:06:45] <Valen> what do you want it for Tom_itx?
[18:07:08] <Tom_itx> not sure really but considered it for a spindle
[18:07:18] <Tom_itx> 3phase with a driver
[18:07:27] <Valen> urgh sounds like a pin
[18:07:28] <Valen> pain
[18:07:28] <Tom_itx> i still gotta figure out the serial interface
[18:07:36] <Valen> oh it comes with driver?
[18:07:42] <Valen> perhaps then
[18:07:45] <Tom_itx> i gutted the whole washer
[18:08:12] <Tom_itx> i figured i could wire up the harness and figure out the signal
[18:08:42] <Tom_itx> either with a scope or logic analizer
[18:09:47] <Tom_itx> it's kinda purpose built since the pulley was turned as part of the shaft
[18:13:48] <skunkworks> andypugh: I suppose with a 3 phase driver - you would have to reverse the phasing..
[18:14:06] <skunkworks> wow - I think I don't understand all the issues you would run into
[18:20:16] <andypugh> No, neither do I with this system.
[18:20:27] <andypugh> But I can definitely do it all in software.
[18:24:06] <PCW> Probably need to invert the encoder position scale and the PID output polarity
[18:25:56] <PCW> resolver position scale I should say
[18:27:01] <PCW> This is one of those places where it would be nice to have a PID output invert option
[18:28:47] <R2E4_> PCW:
[18:28:49] <skunkworks> does that screw up the phasing between the resolver and the motor?
[18:29:33] <PCW> should not if there's a resolver equivalent of encoder raw counts
[18:30:01] <R2E4_> The car cage with the drives in them, there is a board on the right of the card cage which is the interface to the seperate axis drives.
[18:30:42] <R2E4_> The connectors on there goes to the fmdc board and houses the 0-10v signal etc.
[18:30:59] <R2E4_> I have access to that board and I think that is where to interface with the 7i77
[18:31:36] <PCW> So it may be a lot easier that you thought assuming you can figure out the signals at the interface board
[18:31:45] <R2E4_> There is edge connector on that board goes to the backplane
[18:32:23] <R2E4_> I have the exact pins on each signal for each axis on the drawings.
[18:32:59] <PCW> there looked like a lot of just plain old wires so maybe the wires are all you need
[18:34:00] <R2E4_> I wont have to touch the drives, just remove on wires on the interface board that goes to the fmdc. There is where I need to interface.
[18:34:37] <R2E4_> The wires at the bottom of the drives go to the motors
[18:35:00] <R2E4_> Does the mesa boards need any tach data?
[18:35:17] <PCW> No
[18:35:50] <PCW> but the tachs need to get to the drives
[18:36:24] <R2E4_> They do, but there is a parallel out to the fmdc also.
[18:38:31] <R2E4_> Just have to deal with the fault signals
[18:44:09] <syyl_> sometimes you just have luck :D
[18:44:10] <syyl_> https://dl.dropbox.com/u/24396704/IMAG0254.jpg
[18:44:35] <syyl_> ununsed heigh gauge made in eastern germany 1987
[18:48:03] <L84Supper> PCW: do you already have a GbitEthernet FPGA IO board? or is that in the works soon?
[18:51:59] <PCW> Yes with ZYNQ
[18:53:05] <Valen> port emc to arm already
[18:53:15] <Valen> ;->
[18:53:39] <Valen> machine control in a can
[18:55:14] <PCW> LinuxCNC is unlikely to require GigE however
[18:55:36] <Valen> *everything* requires gig-e
[18:55:42] <L84Supper> it's already working on the RPi and the beaglebone and some older arm SOC's
[18:55:55] <Valen> with rt?
[18:56:02] <PCW> Yes
[18:56:08] <Valen> nice
[18:56:09] <PCW> Xenomai
[18:56:14] <L84Supper> xenomai as well IIRC
[18:56:31] <Valen> your board has hdmi/dvi or some such output pcw? and some kind of storage?
[18:57:04] <PCW> ZYNQ board we make will have no video
[18:57:21] <Valen> awww but that'd make it an all in one EMC board
[18:57:28] <L84Supper> PCW: how about an FPGA board with an option DIMM for 1-2GB of DDR3?
[18:57:57] <PCW> ZYNQ will have on card DDR3 RAM
[18:58:09] <L84Supper> 1gb+ ?
[18:58:22] <PCW> Yes
[18:58:26] <L84Supper> good
[18:58:44] <Valen> usb + hdmi and its a computer ;-P
[18:59:13] <L84Supper> PCW: might it ship by june?
[18:59:29] <L84Supper> or whats the time table on ZYNQ?
[18:59:33] <PCW> Its deliberately _not_ a computer
[19:00:03] <PCW> probably mid year, depends on Xilinx as well
[19:01:51] <PCW> The nice thing about ZYNC is it allows us to duplicate the performance of our PCI FPGA cards (say 100 MB/sec) over a Ethernet link
[19:09:50] <Valen> but I *want* it to be a computer l->
[20:40:59] <r00t4rd3d> CNC OVER USB!
[20:50:40] <Tom_itx> usb is too slow
[20:50:47] <Valen> its not too slow
[20:50:51] <Valen> its too jittery
[20:50:59] <Jymmm> Interesting
http://www.youtube.com/watch?v=k5HffZbeNGk
[20:51:41] <ProxDem> and your claims are based on?
[21:03:58] <ProxDem> and compared to what? (curiosity)
[21:22:50] <r00t4rd3d> context?
[21:23:03] <r00t4rd3d> whos claims
[21:25:22] <r00t4rd3d> i need to tear apart my machine again
[21:25:51] <r00t4rd3d> slap on my new z axis :)
[21:26:19] <r00t4rd3d> from 8mm linear rods and pillow blocks to cncrp linear carriages
[21:27:02] <r00t4rd3d> now my z should be stout enough to cut aluminum decently
[21:45:33] <ProxDem> < Tom_itx> usb is too slow < Valen> its not too slow < Valen> its too jittery
[21:46:03] <Valen> usb jitter can be over 20msec
[21:46:14] <ProxDem> if you are not sending pulses
[21:46:18] <ProxDem> but sending words
[21:46:22] <ProxDem> shouldn't matter
[21:46:25] <ProxDem> ?
[21:46:26] <Valen> usb speed is 480mbit
[21:46:33] <ProxDem> Valen: that's usb 2.0
[21:46:44] <Valen> even 12mbit, is "fast" enough
[21:47:00] <Valen> but the data takes a long and variable time to get to the drives
[21:47:26] <ProxDem> one wouldn't be pulse driving via USB
[21:48:01] <Valen> if you are using EMC for the servo thread, then it matters
[21:48:16] <ProxDem> shouldn't a board like mesa makes take care of all that
[21:48:19] <Valen> just add 20msec to your latency and see how it works out for a servo system
[21:48:39] <Valen> close the loop, with lots of jitter in it, its not going to work
[21:48:59] <ProxDem> so mesa board don't have the capability to get info on closing the loops themselves?
[21:48:59] <Valen> you come out of a heavy cut, the mill takes off, then 20 msec later you start winding the power down
[21:49:03] <Valen> no
[21:49:13] <Valen> they do, but its not used by EMC
[21:49:16] <ProxDem> ahhh
[21:49:27] <ProxDem> cause that would illiminate the entire problem
[21:50:55] <skunkworks> but caused a whole bunch of others..
[21:52:58] <R2E4_> Hi all
[21:53:30] <Valen> I can see pushing the servo loop into firmware working well
[21:53:44] <Valen> run the servo loop at 10Khz, would be good for linear motors and the like
[21:54:01] <Valen> but it'd be a job to allow EMC to use that
[21:56:37] <R2E4_> So how does EMC close the loop then?
[21:56:40] <ProxDem> skunkworks: if coded well the xilinx FPGA would be way faster then the PC
[21:57:05] <ProxDem> but HDL and VHDL are a pain
[21:57:14] <ProxDem> hi R2E4_
[21:57:44] <R2E4_> howz it going. Howd you like the dumping today. Its still goin on.
[21:58:19] <ProxDem> it's going ok I guess =) yeah the white sh*t is still pooring
[21:58:36] <ProxDem> pouring*....damn can't spell
[21:58:41] <ProxDem> and how are you?
[21:58:46] <Valen> mesa already have software for their fpga boards to do it
[21:58:51] <Valen> EMC just doesn't use it
[21:59:06] <Valen> EMC does the servo loop in software in the aptly named servo thread
[22:03:18] <pcw_home> We have FPGA code that will run PID loops at 100 KHz but its of no use for LinuxCNC
[22:04:12] <Valen> well it could be of use to EMC, but its not used ;-P
[22:04:50] <Valen> I'd love to run my servo thread nice and quick smart with the torqueish mode drive you get from the rest of the chain
[22:05:31] <pcw_home> LInuxCNC has all real time code in one place, if real time code is scattered (and uses non real time links like USB)
[22:05:33] <pcw_home> you have a much uglier and less flexible control model
[22:05:39] <Err> pcw_home: so what is that normally used for? can you set an acceptable error term, and then the FPGA just interrupts if the error term is exceeded?
[22:06:22] <pcw_home> Its a complete multi axis motion system
[22:07:13] <Valen> it could replace everything after the planner pretty much?
[22:08:07] <pcw_home> For machine tools, unless you are doing something exotic you are going to have diminishing returns above 4 KHZ or so so for LInuxCNC theres not much point
[22:08:35] * Valen is damn exotic
[22:08:56] <Err> does Mesa have complete motion control IP, then, for non-LinuxCNC applications?
[22:09:47] <pcw_home> Mhaberlers separation of the real time bits into MachineKit will probably allow 10-20KHz servo thread systems and still have HAL
[22:10:38] <pcw_home> Yes we have SoftDMC which is a complete (if simple) up to 8 axis servo motion contrlloer
[22:10:38] <Valen> thats seperate from your ZYNQ yes?
[22:10:54] <Valen> machinekit that is
[22:11:32] <Valen> hmmm, how many I/O's will there be on your ZYNQ?
[22:11:41] <pcw_home> I expect that the ZYNQ would be an ideal machinkit target
[22:11:52] <Valen> I have an application that needs an assload and a half of PWMs
[22:12:01] <pcw_home> 7010 has 100 I/O
[22:12:19] <Valen> dang, I'm around 150
[22:12:22] <pcw_home> (FPGA I/O processor I/O is separate)
[22:12:39] <pcw_home> use a 3X20 (144)
[22:14:24] <L84Supper> pcw_home: can you use any of the IO configured as LVDS on the ZYNQ board?
[22:14:33] <pcw_home> Yes
[22:15:15] <pcw_home> I think just about all of it is LVDS pairs
[22:15:16] <Valen> hmm, could work
[22:16:11] <Err> if your PWM isn't very fast, I wouldn't think you would need LVDS (which could double your pin density)
[22:16:14] <L84Supper> looks like it could be used as a printhead controller
[22:17:03] <pcw_home> Yeah dual GigE, and very fast CPU-FPGA connection
[22:17:19] <L84Supper> all it might need is a 150VDC programmable pulse generator with adjustable slew ~40V/uS
[22:17:43] <Valen> I'm running an array of piezo's they want about 300hz movement on the output
[22:18:03] <Err> heh, that's a serious pulse generator
[22:18:57] <Err> (assuming you're driving any sort of load at that slew rate)
[22:19:21] <L84Supper> yeah, but it only needs to fire up to ~60khz
[22:20:25] <L84Supper> ~150 pF load
[22:21:40] <L84Supper> 200pF max
[22:26:15] <L84Supper> an industrial inkjet printhead controller starts at ~$200K, so this could potentially upset quite a few people if LinuxCNC suddenly had support for them
[22:27:10] <Valen> would need hacking on emc to get it to output like that
[22:27:25] <Valen> it'd probably be simpler to just roll your own firmware
[22:27:38] <Valen> unless you are saying to XYZ control the head as well as print
[22:30:43] <L84Supper> yeah, the heads or the substrate moves, it all has to be coordinated
[22:31:33] <Valen> it'd make laser rastering easier too ;->
[22:32:20] <Err> L84Supper: out of curiosity, what is such a printhead used for?
[22:33:24] <L84Supper> Err: it usually an array, and it could be a wide format inkjet printer for posters/banners or used for materials deposition...
[22:33:42] <L84Supper> printed electronics, 3d printing etc etc
[22:34:00] <Err> OK, so you mean the controller *design* has that value - not that every instance of one costs that much
[22:34:07] <Err> (or am I mis-understanding?)
[22:35:07] <L84Supper> no, an actual controller lists for $200K and up, if you want to build a custom printer
[22:35:43] <L84Supper> complete inkjet printers are sold for less, but then you only get what they have configured
[22:36:34] <Err> OK, sure, I understand what you're saying
[22:36:40] <Err> I've never tried to build a printer from scratch :-)
[22:41:01] <L84Supper> http://imagebin.org/250942 the printhead controller is on the right
[22:41:54] <Err> wow
[22:41:59] <Err> that's an impressive piece of kit
[22:42:49] <L84Supper> the PC under the table has two servo amps and some mesa boards inside the case
[22:57:15] <tjtr33> hello, what does the IM mean in some Mesa bit file names, like SV12IM_2X7I48_72.BIT ?
[22:59:53] <pcw_home> Index mask
[23:01:19] <tjtr33> hey thx, and what are the references to (tbl3) and (tbl5) ? stepping types?
[23:02:01] <tjtr33> http://linuxcnc.org/docs/html/drivers/hostmot2.html
[23:04:33] <pcw_home> tbl?
[23:05:51] <tjtr33> i dunno the indo on hostmot2 shows some stepgens wiht a thing that looks like a footnote saying (tbl3) and a few more with (tbl5)
[23:06:04] <tjtr33> could be a funny font, but i think its an 'el'
[23:06:07] <pcw_home> Oh the stepgen hardware has a 6 wide 16 deep table for output sequence options but its remains unsupported by LinuxCNC
[23:06:34] <tjtr33> great thx
[23:06:53] <pcw_home> (so TBL0 - step TBL1 = DIR TBL2..5 are unused)
[23:07:08] <tjtr33> i finally got the entire 14.4 xilink tutor to run, was hell, not too much patching.
[23:07:50] <tjtr33> big trick is... install full linux single download ( NOT webpack), then use webpack license... you get all the gooodies then
[23:08:21] <tjtr33> some fonts, a couple libs, and hack up a desktop lawnchair in dufus unuity
[23:08:23] <pcw_home> right webpack is just a license option
[23:08:51] <tjtr33> >that< is very not intuitive thing to do :)
[23:09:17] <pcw_home> I don't think I've ever installed successfully except via DVD
[23:10:04] <tjtr33> but it runs now, will try to build a stock bit file and begin one of the books Chu
[23:10:53] <tjtr33> i'd like to add a precision timer in the unused gates on my 5i20
[23:11:24] <tjtr33> so getting the IP cores was a good thing
[23:12:35] <pcw_home> You can actually do that with just the stepgen (set for a reasonable rate)
[23:14:54] <tjtr33> ummm, a programmable pulse is more exact description, on time & off time independantly programmable
[23:15:25] <tjtr33> 1uS rez, from 1 to say 4092 each? that possible, as is?
[23:16:05] <tjtr33> 1uS ... i dotn think thats 'reasonable' huh?
[23:16:25] <pcw_home> single pulse or rate?
[23:16:52] <tjtr33> indiv pairs, like one trigger cause 1 on followed by 1 off followed by wait for the trigger
[23:17:23] <tjtr33> the wait may be 1uS tho
[23:17:27] <tjtr33> as little as
[23:19:12] <pcw_home> that would probably need custom hardware but should be simple
[23:19:14] <pcw_home> (If you use normal 5I20 HS clock= 100 MHz you could have delays from 10 ns to ~40 seconds is 10 ns steps with a 32 bit time register)
[23:20:18] <tjtr33> yes in the tutor examples i was seeing it could be 'damn' fast, and figgered a clock and some counters, maybe scaling the clock
[23:20:32] <tjtr33> cuz i dont need the fine rez at the higher values
[23:20:59] <pcw_home> but a 32 bit register is not a big deal
[23:21:21] <pcw_home> bbl leepy...
[23:22:01] <tjtr33> thx, gnite
