#emc | Logs for 2005-11-20

Back
[02:30:46] <paul_c> fenn: I have better things to do with my time than read BS
[02:30:49] <fenn> well there goes that theory
[02:30:50] <petev> All I want to be able to have an MPG, HW cycle hold/start, etc.
[02:30:55] <alex_joni> petev: what's wrong with what I suggested?
[02:31:18] <petev> You are suggesting making all new messages for NML
[02:31:32] <petev> that's a big job and doesn't address the simple HAL widgets
[02:31:35] <alex_joni> not that.. about the GUI blocks
[02:31:39] <petev> how will they talk to the HAL?
[02:31:56] <alex_joni> I suggested writing another piece like iocontrol (but the other way around)
[02:31:57] <petev> Oh, you mean the HAL version of emcsh?
[02:32:04] <alex_joni> those two might actually be in one piece
[02:32:06] <alex_joni> right
[02:32:10] <paul_c> why the hell would anything (in usr space) want to use hal ?
[02:32:32] <alex_joni> paul_c: the talk is about using GUI widgets compatible with actual buttons
[02:32:33] <petev> we want to be able to replace a HW button with SW
[02:32:39] <petev> and have it act exactly the same
[02:32:44] <alex_joni> so the integrator can chose which one he wants
[02:32:55] <petev> for testing, for GUI customization, etc.
[02:33:31] <petev> ok, so the HAL emcsh would export pins determined by some config file?
[02:33:45] <petev> wouldn't it require HAL to run on a remote machine?
[02:33:53] <alex_joni> so?
[02:34:03] <paul_c> Oh woopie... More crappy config files with yet another format.
[02:34:04] <alex_joni> if you want buttons on a remote machine, you need HAL there
[02:34:05] <petev> that's ugly
[02:34:16] <petev> I want the equivalent of a long peice of wire
[02:34:21] <petev> not a HAL for nothing
[02:34:24] <alex_joni> even if you use RPC or whatever
[02:34:29] <petev> no
[02:34:32] <alex_joni> petev: you need the drivers
[02:34:40] <alex_joni> don't say you're not seeing that
[02:34:43] <petev> remote HAL widget makes RPC call to HAL on real machine
[02:34:49] <petev> no
[02:34:57] <petev> only for HW on real machine
[02:35:02] <petev> not on remote GUI machine
[02:35:10] <alex_joni> I need HW on remote machine..
[02:35:14] <petev> why do I need drivers on remote GUI machine?
[02:35:19] <petev> why?
[02:35:20] <alex_joni> if I want the GUI there.. then I want some buttons next to it
[02:35:26] <fenn> so you can hit the big red button on your desk in the office!!!
[02:35:29] <petev> not necessarily
[02:35:39] <alex_joni> or else the whole thing has no need for further talks
[02:35:48] <petev> could be a SW only for uploading new programs for the operator
[02:35:52] <alex_joni> you don't get any improved functionality from what you have now
[02:35:55] <petev> could be for test/dev
[02:35:57] <petev> etc.
[02:36:11] <petev> sure, I don't have to put a HAL on my remote machine
[02:36:23] <petev> and I think the work of HAL emcsh gets dirtributed
[02:36:39] <petev> and naturally gets modifed to support new widgets
[02:37:39] <petev> how would HAL pin to NML message mapping be setup with HAL emcsh
[02:37:47] <alex_joni> ok.. rewind a bit and state the goal again
[02:38:07] <petev> why go through all the work to make a user mode only HAL that runs posix threads?
[02:38:25] <petev> goal is to have GUI building blocks like we have for HAL
[02:38:39] <petev> and that they work remotely without having to run HAL on remote machine
[02:38:44] <paul_c> rather than pratting around with re-implementing a communications protocol, why not just add a general purpose NML message that you can use to wiggle a HEL pin ?
[02:38:50] <alex_joni> ok.. so we are talking about GUI building blocks?
[02:38:58] <petev> yes
[02:39:12] <alex_joni> * alex_joni is not interested in GUI design
[02:39:31] <petev> why not?
[02:39:34] <alex_joni> if you want to write another GUI.. be my guest
[02:39:38] <petev> can't run a machine without one
[02:39:54] <petev> non of the current GUI are that great for a real machine
[02:39:55] <alex_joni> I am perfectly happy with all 5 gui's I'm running here
[02:39:58] <paul_c> If you are going to be messing around with GUI "widgets" you are going to need to write wrappers (or bindings if you prefer) for the messages
[02:40:11] <alex_joni> paul_c: that's what he has been suggesting
[02:40:16] <petev> yes, that's one of the issues I have with NML
[02:40:26] <petev> the bindings can't be made app neutral
[02:40:41] <paul_c> regardsless of them being RPC, NML, simpl, dbus, or fenn's magical "just do it" library.
[02:40:47] <petev> due to the fact that the NML messge must be inherited and the way the messages are defined
[02:41:01] <petev> you know NML much better than me
[02:41:06] <paul_c> so what does RPC solve ?
[02:41:08] <petev> so I ask the following
[02:41:21] <petev> what features of NML are important to EMC?
[02:41:32] <paul_c> all of them.
[02:41:45] <petev> I read the NIST doc, but they don't explain any reasons for architecture, or thinking
[02:41:59] <petev> be specific please
[02:42:05] <paul_c> have you read the RCS Handbook ?
[02:42:18] <petev> I read a 90 page NIST doc on NML
[02:42:23] <petev> not sure if that's the one you mean
[02:42:43] <alex_joni> the RCS Handbook is a book
[02:42:46] <alex_joni> you can find it on amazon
[02:42:50] <paul_c> 284 pages in the handbook.
[02:42:55] <alex_joni> I got one for 10$
[02:42:56] <petev> no, don't have it
[02:42:57] <fenn> * fenn rolls his eyes
[02:43:04] <alex_joni> morning fenn
[02:43:15] <paul_c> * paul_c got one free from Fred Proctor.
[02:43:16] <fenn> nah it's night time
[02:43:23] <petev> paul: can you just point out a few feature that are unique to NML that EMC needs?
[02:43:29] <petev> this is a seious question
[02:43:35] <petev> serious
[02:43:40] <fenn> petev's more persistent than i am.. i lost interest in this conversation a couple hours ago..
[02:43:42] <petev> I really don't understand
[02:44:05] <paul_c> rcslib (or libnml) provides a number of services...
[02:44:20] <petev> ok...
[02:44:53] <paul_c> a) data buffers with full protection against concurrent read/writes
[02:45:26] <paul_c> b) a configuration file that allows you to define where and how the buffers are used.
[02:45:50] <paul_c> c) blocking and non-blocking read/writes
[02:46:11] <paul_c> d) one to many and one to one communications
[02:46:27] <paul_c> e) buffered nessage queues
[02:46:35] <alex_joni> d). and many to one comms
[02:47:12] <petev> ok, but pretty much all of these can be done with most RPC, except for maybe E
[02:47:27] <alex_joni> petev: e) comes in handy on IO stuff, if one command is executing the next get saved and run after that
[02:47:27] <petev> where do you see NML being better?
[02:47:32] <paul_c> g) a mature and platform independant communications library that can be compiled on a number of incompatable computers.
[02:47:46] <alex_joni> that's what's happening for tool-change in emc2 now
[02:48:22] <petev> well so far I see 2 things in NML
[02:48:37] <petev> being able to use a backplane like VME for the channel
[02:48:49] <paul_c> h) Simple methods exist for reading and writing messages that isolate the programmer from the underlying operating system.
[02:48:54] <petev> and a buffered message queue
[02:49:29] <petev> seems like NML adds a lot of complication for a couple of features
[02:49:37] <alex_joni> petev: probably all of the above can be replicated using any other message passing library out there (but that involves some aditional coding)
[02:49:52] <alex_joni> notice I am talking about message passing, not RPC
[02:50:02] <petev> seems like a queue class could easily be implemented and used in the receiveing objects that require it
[02:50:12] <paul_c> OK.. What work is involved in re-implementing a communications library on the back of RPC ?
[02:50:15] <petev> alex: agreed
[02:50:30] <alex_joni> all the above work..
[02:50:32] <petev> I'm not suggesting that we do that right now
[02:50:51] <petev> what I would like to try first is building an RPC wrapper for libhal
[02:51:00] <petev> then making HAL widgets that use it directly
[02:51:12] <petev> we can see how that goes first
[02:51:15] <paul_c> for a start, libhal has some major flaws.
[02:51:29] <petev> such as?
[02:51:42] <petev> pointers to SHME?
[02:51:45] <petev> SHMEM
[02:51:48] <paul_c> aside from the butt ugly config files ?
[02:52:12] <petev> well, I don't think the config files are that bad, so what else?
[02:52:30] <alex_joni> the problem with configuring only at insmod time
[02:52:37] <paul_c> no data types defined for doubles.
[02:52:50] <petev> paul: can be added
[02:52:59] <alex_joni> and needing to shut down the whole system to change a setting (I know this is addressed in the refactor)
[02:53:09] <alex_joni> but no-one seems to be working on that right now
[02:53:41] <petev> ok, these seem minor in comparison to having building blocks for a GUI
[02:53:41] <paul_c> The fact that a kernel module can be unloaded at ANY time - but that is an implementation issue..
[02:54:22] <petev> paul: so how would you suggest we get to the point where we have flexible building blocks for GUIs?
[02:54:51] <petev> If I want an MPG and HW cycle stop/start and feed/speed overrides, how do I get them?
[02:54:52] <paul_c> starting at the bottom ?
[02:54:56] <petev> sure?
[02:55:25] <petev> I can plug them into the HAL and get as far as HAL pins, but what next?
[02:55:43] <paul_c> Forget all about HAL - It solves nothing, and just adds to the crappy code base making all the same mistakes as NIST did.
[02:55:58] <fenn> wow
[02:56:03] <petev> ok, from the bottom the way you see it
[02:56:52] <paul_c> Decide what language you want to use for your widgets - Be it Qt, fltk, python, etc
[02:58:25] <petev> say we want bindings for all of the above
[02:58:35] <petev> and maybe Gtk too
[02:58:55] <paul_c> bindings does not equal widgets.
[02:59:03] <petev> bindings and widgets
[02:59:29] <petev> So C++, C, tcl, python
[03:00:18] <paul_c> C++, tcl, and python already have wrappers around NML messages.
[03:00:29] <paul_c> C is a subset of C++
[03:00:47] <petev> yes, but I can't add and MPG yet
[03:00:53] <petev> how do I do that?
[03:01:19] <petev> no widget needed for an MPG
[03:01:22] <petev> use a HW one
[03:01:25] <paul_c> and an "MPG" is what exactly ?
[03:01:47] <petev> let's work bottom up, then talk widgets for simple things like switches
[03:01:59] <petev> MPG, manual pulse generator or a jog wheel
[03:02:14] <petev> pretty common thing to want
[03:02:29] <paul_c> i.e. An encoder or 360Deg. pot.
[03:02:35] <petev> sure
[03:02:42] <petev> use encoder
[03:02:55] <paul_c> Got one on the Bridgeport here.
[03:03:02] <petev> I think pots violate the NIST control ideas
[03:03:11] <petev> ok, so how does it work?
[03:03:26] <paul_c> matters not what the actuall sensor is..
[03:04:00] <petev> well, it's a bit difficult to make a pot position indepentant if there is also a SW control
[03:04:06] <petev> that's what I meant
[03:04:12] <paul_c> I select which axis to control, optionally, the resolution I want. Then spin the sucker.
[03:04:28] <petev> ok, but how does it work with EMC
[03:05:08] <paul_c> The Bridgeport uses a Heidenhain control.
[03:05:16] <petev> well that's no help
[03:05:25] <petev> let's talk EMC
[03:05:28] <petev> how do I get on on an EMC machine?
[03:06:06] <fenn> you make a hal component, write an nml wrapper that exports a hal pin for the "jog" message
[03:06:24] <petev> that's not Paul's way
[03:06:29] <fenn> oh, sorry
[03:06:30] <petev> he doesn't even want HAL
[03:07:00] <petev> and I want to be able to do it without having to write code
[03:07:03] <paul_c> quick'n'dirty - Write a small chunk of code that reads the jog wheel, and then issues a new position command
[03:07:08] <alex_joni> petev: I'd suggest looking at the component that there is in emc
[03:07:09] <petev> the same way I can configure HAL
[03:07:20] <alex_joni> emc1 that is.. has a handwheel interface
[03:07:21] <petev> alex:which component?
[03:07:35] <alex_joni> hang on.. looking for the name
[03:07:35] <petev> I'm trying to understand what Paul would like as the architecture
[03:07:59] <petev> As an integrator I may not know how to write code
[03:08:09] <petev> why can't I have GUI building blocks?
[03:08:30] <alex_joni> handwheel.cc / handwheel.hh
[03:08:46] <alex_joni> an external handwheel is a GUI building block?
[03:08:56] <alex_joni> * alex_joni doesn't see that
[03:08:58] <paul_c> You want a drag'n'drop GUI designer like Mach2/3/4 ?
[03:09:18] <alex_joni> * alex_joni uses Mach3 once in a while
[03:09:18] <petev> sorry, I'm lumping it all together, the GUI blocks, SW buttons, etc.
[03:09:42] <petev> I would settle for widgets I could use in QT designer myself
[03:09:48] <alex_joni> pretty decent razors
[03:09:53] <petev> others may want more
[03:10:01] <paul_c> As an integrator, do you want a drag'n'drop GUI designer like Mach2/3/4 ?
[03:10:21] <petev> that would be great
[03:10:41] <petev> but an integrator may be able to handle QT designer if the widgets were good
[03:10:58] <petev> and required no other programming
[03:11:06] <paul_c> You have a choice then - Either learn how to write some hooks for gambas, or pay someone to do it.
[03:11:27] <petev> I'm not talking about myself
[03:11:28] <alex_joni> gambas? wot's that?
[03:11:33] <petev> I can write my own code
[03:11:45] <petev> I'm talking about an architecture for EMC
[03:12:07] <petev> are you telling me your architecture is to just write custom code when required?
[03:12:38] <petev> gambas is a graphical basic
[03:12:50] <petev> it's open source
[03:13:10] <paul_c> No. I'm saying - I'm not going to mess around writing code for other people unless I get paid for my time.
[03:13:46] <paul_c> IF it is something closely connected with someting I am already involved with, then that is a different matter.
[03:14:06] <petev> then why come on IRC and say it's all wrong but not suggest what's right?
[03:14:38] <paul_c> There is nothing intrinsically wrong with NML
[03:14:56] <Jacky^> hey
[03:15:04] <alex_joni> paul_c: maybe lack of understanding (and hence documentation)
[03:15:09] <petev> ok, so in your opinion how would you implement a MPG in EMC?
[03:15:15] <Jacky^> open source its nice
[03:15:31] <paul_c> without someone writing some code somewhere ?
[03:15:46] <petev> yes, that would be the goal
[03:15:52] <Jacky^> * Jacky^ is reading about City Academy di Bristol experiment payng students to learn..
[03:15:55] <Jacky^> O_O
[03:16:03] <petev> somebody would write some code that an integrator could just configure
[03:16:09] <alex_joni> code is needed .. you don't have the code to do that now, so someone must write it
[03:16:10] <Jacky^> they will become excellent M$ developers !
[03:16:26] <alex_joni> configure might also mean chosing a component or not..
[03:16:28] <petev> yes, the somebody is the developers, no code for integrator
[03:16:45] <alex_joni> paul_c wasn't talking about integrators coding
[03:16:55] <alex_joni> integrators use what exists
[03:16:56] <paul_c> FACT: Someone MUST write code.
[03:17:11] <petev> ok, well obviously we need code by developers, so that's fine
[03:17:18] <alex_joni> and maybe (but I didn't see that) use the Feature Request Tracker for new features
[03:17:25] <petev> but not code that has to get written for every special case
[03:17:26] <paul_c> FACT: There are NO integrators using EMC in volume.
[03:17:32] <Jymmm> * Jymmm brings in 100 monkeys..
[03:17:37] <alex_joni> I see an administrative problem in emc
[03:17:44] <fenn> * fenn gives jymmm a genetic algorithm typewriter
[03:17:45] <alex_joni> you have limited developer time
[03:17:47] <Jymmm> paul_c sherline?
[03:17:55] <paul_c> alex_joni: There isn't any.
[03:18:05] <alex_joni> and you need to fix bugs (urgent imnsho)
[03:18:18] <alex_joni> then you need to take care of existing trackers
[03:18:22] <paul_c> Jymmm: Sherline are (for the want of a better term) box shifters.
[03:18:23] <alex_joni> and add new ones, address those..
[03:18:43] <alex_joni> that's if you want to use the SF admin tools, as it has been decided a few years ago
[03:18:56] <petev> I think there is more developer time than you think
[03:19:08] <petev> the problem is there is no plan or guidance
[03:19:13] <petev> that's what's needed
[03:19:23] <alex_joni> the stuff at SF should be enough for starters
[03:19:27] <petev> I could have been writing code for the last 2 hours if there was a plan
[03:19:43] <alex_joni> petev: you think open bugs need a plan?
[03:20:01] <petev> I think they need assignment to a developer
[03:20:06] <paul_c> petev: Write to the emc-board list.
[03:20:07] <alex_joni> * alex_joni has been closing more than 5 bugs last month..
[03:20:14] <petev> but there are a lot of developers that are doing nothing
[03:20:38] <alex_joni> Bugs : (16 open / 45 total)
[03:20:48] <alex_joni> Feature Requests : (20 open / 37 total)
[03:20:50] <paul_c> There are a hell of a lot of names registered that shouldn't be there.
[03:20:59] <petev> maybe if we had a good plan and a good architecture and some docs to work from
[03:21:07] <petev> it would reduce the number of bugs as well
[03:21:07] <paul_c> T. Goldstein for one..
[03:21:19] <alex_joni> petev: if a developer can't decide that fixing a bug is needed.. well then I really can't say..
[03:21:36] <alex_joni> ok.. how about docs?
[03:21:39] <alex_joni> who does that?
[03:21:48] <alex_joni> did you see any volunteers?
[03:21:48] <petev> so you think all developers should be fixing bugs right now?
[03:21:53] <alex_joni> even the new stuff has limited docs
[03:21:58] <petev> I this we need a plan first
[03:22:05] <petev> hard to fix stuff without a plan
[03:22:16] <Jacky^> you need a stupid user like mt to find bugs first :P
[03:22:19] <alex_joni> you keep changing topic
[03:22:41] <petev> no, I'm looking for the plan and architecture for EMC2
[03:22:52] <petev> without it I can't be of much help
[03:23:03] <petev> the HAL is clearly defined and I can contribute there
[03:23:05] <alex_joni> you could write some docs?
[03:23:08] <fenn> i think you should write the docs first, (api) then implement it
[03:23:13] <alex_joni> especially on the code you did..
[03:23:13] <petev> but outside of that it's chaos
[03:23:26] <petev> fenn:agreed
[03:23:29] <alex_joni> * alex_joni points to classicladder
[03:23:46] <petev> All of the HAL code is commented in the header better than the other HAL code
[03:23:50] <petev> the CL was just a port
[03:23:55] <paul_c> * paul_c points to the Mesa code which probably is not GPL.
[03:23:57] <petev> certainly not my code
[03:23:59] <petev> it is ugly
[03:24:09] <petev> paul:how so?
[03:24:28] <alex_joni> it's not stated GPL..
[03:24:28] <petev> I got permission to release the FPGA code and it's available on the Mesa website
[03:24:36] <paul_c> There is NO copyright details in ANY of the Mesa files.
[03:24:50] <petev> well, I suppose we can add them if that's the issue
[03:25:11] <alex_joni> if you got permission to add the headers, then please do asap
[03:25:16] <petev> if you guys don't want it in the CVS, delete it
[03:25:25] <paul_c> and "permission to release" does not confer GPL status on it unless the original author has given explicit permission.
[03:26:37] <petev> well, I asked Peter Wallace from Mesa and he is the author
[03:26:41] <petev> it's his company
[03:27:04] <petev> this is way off track
[03:27:16] <alex_joni> you asked him if you can mark the code as GPL, and he agreed?
[03:27:22] <petev> what are the proirities for EMC dev as the board see it then?
[03:27:36] <fenn> HAL is LGPL anyway so it doesn't matter.. next!
[03:27:39] <alex_joni> petev: there is no emc board right now..
[03:27:55] <paul_c> From mesanet.com - "firmware is included free with all Mesa FPGA based cards and can be licensed for a nominal charge for non-Mesa cards and embedded FPGA designs."
[03:28:30] <paul_c> fenn: HAL is linked to some GPL code, so it is NOT LGPL
[03:28:32] <alex_joni> fenn: it's not an issue about linking the mesa driver to HAL, but hosting the stuff on SF
[03:28:52] <petev> so, delete it
[03:29:01] <petev> Peter Wallace said it was fine
[03:29:03] <paul_c> alex_joni: Correct - It is in breach of the SF T&C
[03:29:10] <alex_joni> why? is that better than changing it to GPL?
[03:29:11] <petev> but the driver doesn't need the FPGA source up there to work
[03:29:16] <alex_joni> with proper support?
[03:29:22] <petev> it's simply for reference
[03:29:36] <petev> anyone can just go get it from the Mesa site if they want it
[03:29:44] <SWP_Away> SWP_Away is now known as SWPadnos
[03:29:49] <petev> alex: what do you mean?
[03:30:06] <alex_joni> is deleting it any better than just marking it GPL?
[03:30:21] <alex_joni> you said the guys at Mesa probably won't mind..
[03:30:42] <SWPadnos> It seems unlikely that Mesa would want somebody to get their code as part of EMC, and then use it on a non-Mesa card.
[03:30:42] <petev> no, but paul seems to be implying that we need some written permission or something more than a verbal ok
[03:30:49] <SWPadnos> you do
[03:30:50] <alex_joni> so I don't see why we are talking about this for 10 minutes, when the matter might have been addressed a lot
[03:31:03] <petev> well it's on their website now for free download
[03:31:09] <alex_joni> easier than this..
[03:31:13] <paul_c> No. I did not imply. It is essential that written permission is given
[03:31:16] <alex_joni> petev: that doesn't mean anything..
[03:31:18] <petev> and Peter Wallace said it was fine to put in SF
[03:31:19] <petev> so go figure
[03:31:25] <petev> they are selling HW
[03:31:38] <petev> alex: what doesn't mean anything?
[03:31:43] <SWPadnos> but not free use - "for use with Mesa ... small fee for other cards"
[03:31:46] <Jacky^> * Jacky^ agreed with paul_c
[03:31:59] <petev> posting on SF makes it no less secure than it was and we got the ok from Mesa
[03:32:05] <petev> so what is the issue
[03:32:09] <alex_joni_> I can put a win2000 server datacenter edition up for download
[03:32:11] <alex_joni_> for free..
[03:32:14] <petev> if that's not good enought, just delete it
[03:32:20] <alex_joni_> that still won't mean it's GPL...
[03:32:20] <SWPadnos> petev, did you get an email, or was this a verbal conversation?
[03:32:27] <petev> yeah, but MS didn't ok that
[03:32:43] <petev> no, it was verbal as I was talking to him quite a bit
[03:32:43] <alex_joni_> petev: what if someone at MS would ok that?
[03:32:56] <petev> while writing the driver and fixing FW issues, etc.
[03:33:03] <SWPadnos> OK -can you email him, and ask for permission to place it under GPL?
[03:33:08] <petev> many of the FW features came from the EMC driver work
[03:33:14] <alex_joni_> there is a big difference about having free code (download, etc) and marking it as GPL
[03:33:23] <petev> sure, I can email him
[03:33:31] <SWPadnos> thanks - can we move on now?
[03:33:51] <alex_joni_> alex_joni_ is now known as alex_joni
[03:34:07] <alex_joni> SWPadnos: there is no moving on till you get a new board
[03:34:18] <alex_joni> and that seems to have been forgotten
[03:34:19] <SWPadnos> well - we can just act like a board for a while ;)
[03:34:26] <alex_joni> who? you?
[03:34:33] <SWPadnos> nothing is official - this is discussion
[03:34:35] <alex_joni> or me?
[03:34:42] <fenn> nothing is official anyway
[03:34:43] <alex_joni> won't work
[03:34:50] <alex_joni> fenn: that's the main problem
[03:34:51] <SWPadnos> we can talk about it all we want, and then the new board can read the logs
[03:34:56] <jmkasunich> speaking of that - I thought we had a volunteer to send out ballots?
[03:35:04] <SWPadnos> Chris Daniel(s)
[03:35:08] <alex_joni> jmkasunich: indeed we had / have
[03:35:28] <SWPadnos> ah - Daniel, no 's'
[03:35:30] <alex_joni> but seems we need a new one
[03:36:21] <jmkasunich> so what is the topic? sounds like you guys are getting heated up
[03:36:30] <fenn> nml vs rpc again
[03:36:40] <SWPadnos> HAL vs the world
[03:36:52] <SWPadnos> refactor vs kludges
[03:36:53] <alex_joni> jmkasunich: it's that time of the year again
[03:36:54] <Jymmm> This document and the data disclosed herein is not to be reproduced, used,
[03:36:54] <Jymmm> disclosed in whole or in part to anyone without the written permission of MESA ELECTRONICS.
[03:36:55] <paul_c> or "How to implement an MPG without writing any code"
[03:37:13] <alex_joni> every once in a while someone steps up that has a better idea than NML
[03:37:25] <paul_c> Jymmm: Where did you find that ?
[03:37:25] <SWPadnos> only to beaten down with large bats
[03:37:29] <SWPadnos> to be ...
[03:37:38] <Jymmm> paul_c: front page of theri manuals
[03:37:53] <paul_c> BINGO !
[03:37:54] <SWPadnos> the manual isn't the code, but it's probably relevant
[03:37:59] <alex_joni> SWPadnos: we're not trying to beat anyone down..
[03:38:15] <SWPadnos> heh - only kidding ;)
[03:38:17] <alex_joni> but personally I am tired of that talk..
[03:38:19] <Jymmm> SWPadnos "...and the data disclosed herein "
[03:38:24] <SWPadnos> (not them, just their ideas :) )
[03:38:38] <petev> Well I just sent Peter at Mesa an email
[03:38:41] <alex_joni> and it's only talk, no single proof of concept or anything
[03:38:46] <alex_joni> petev: good
[03:38:56] <fenn> "no proof of concept" vs vaporware
[03:38:59] <Jymmm> I'm just tired of everyone whining about mesa code and nobodys gotten anything.
[03:39:03] <petev> I really don't think it's a problem as he pushed for me to release it so a customer could use it with EMC
[03:39:04] <SWPadnos> thanks, petev
[03:39:48] <paul_c> with that out of the way, back to the original topic..
[03:40:10] <alex_joni> HAL with RPC hooks
[03:40:17] <alex_joni> :-/
[03:40:36] <SWPadnos> and reconfigurable GUI blocks
[03:40:45] <alex_joni> SWPadnos: that's another issue
[03:40:52] <SWPadnos> ok - topic 2
[03:42:52] <SWPadnos> ok - discuss!
[03:43:01] <fenn> friday night fights, begin!
[03:43:04] <paul_c> side note: Just deleting a file from CVS does not remove it entirely - It still remains in the history and can be retrieved at any time with a -D flag.
[03:43:14] <jmkasunich> I'm afraid I don't understand the "HAL with RPC" thing
[03:43:45] <SWPadnos> two things: 1) allow userspace apps to act just like hardware (as far as HAL is concerned)
[03:43:54] <SWPadnos> 2) allow remote GUIs to control HAL
[03:44:02] <fenn> jmk fakes a block, dives to the left, *kablammo*
[03:44:04] <SWPadnos> (possibly some other nuances I missed)
[03:44:42] <alex_joni> jmkasunich: petev was suggesting adding hal_lib with RPC hooks
[03:44:59] <alex_joni> so that code on another machine might work calling the HAL code on this machine
[03:45:11] <jmkasunich> I don't see the need for that
[03:45:14] <paul_c> you're lacking a double data type in HAL, so that limits what you can do with respect to a Jog wheel..
[03:45:18] <alex_joni> so if he writes widgets and other GUI stuff, those can call the HAL parts
[03:45:42] <alex_joni> paul_c: you can do even byte-only jog wheels
[03:45:43] <jmkasunich> the jog wheel can (and probably should) use an integer type
[03:45:48] <alex_joni> won't get you very far though..
[03:45:49] <alex_joni> :D
[03:45:53] <SWPadnos> doubles and other large datatypes are a non-issue
[03:46:07] <petev> john k: I see it like a long wire to where I want the button or other HW type widget
[03:46:35] <petev> why have to run the HAL on a remote machine?
[03:46:37] <paul_c> If you want GUI widgets to display position data from HAL, then you will need a double
[03:46:45] <jmkasunich> HAL is inherently local
[03:46:50] <SWPadnos> doubles could possibly be a memory issue, but not an architectural one
[03:47:04] <jmkasunich> exactly - a red herring for the current discussion
[03:47:06] <Jymmm> I'll shutup after this... WTH is everyone so fucking concerned with the GUI?! There are a LOT of other things that could use a lot more effort in. The damn thing already has 4 GUI's as it is and can't even thread. </soapbox>
[03:47:21] <SWPadnos> you can always use double buffering - it can cause some delays, but no incomplete writes (the only assumption is that a pointer write is atomic)
[03:47:22] <petev> ok, but what if I want a SW HAL widget on a remote machine?
[03:47:25] <alex_joni> Jymmm: spot on
[03:47:44] <alex_joni> GUI should not use HAL, imho
[03:47:46] <SWPadnos> (no pun intended)
[03:48:00] <petev> jymm: because we can put all kinds of stuff in the HAL and the GUI can't control it
[03:48:06] <alex_joni> except for the case where you use actual Hardware to control the machine.. but that's UI not GUI
[03:48:07] <jmkasunich> I agree with alex, except for one situation - pendants (or other "real" controls)
[03:48:18] <petev> pretty worthless if you can't use the feature because the GUI is in the way
[03:48:38] <alex_joni> what do you mean "GUI is in the way" ?
[03:48:42] <petev> jmk: agree with what?
[03:48:51] <petev> you mean no remote SW widgets?
[03:49:04] <jmkasunich> <alex_joni> GUI should not use HAL, imho
[03:49:20] <petev> GUI shouldn't use HAL?
[03:49:23] <petev> why not?
[03:49:31] <SWPadnos> there are situations where the GUI may need to act like a piece of hardware (to the rest of the system)
[03:49:34] <petev> what about simple buttons like cycle stop/start?
[03:49:36] <jmkasunich> I would like to see a GUI that has the option of using HAL to access physical devices instead of on-screen devices
[03:49:36] <alex_joni> jmkasunich: if you say that I'll change imho to imo ;)
[03:49:45] <petev> you want to treat a SW button different than HW?
[03:49:45] <jmkasunich> but I wouldn't force the GUI to use HAL
[03:50:07] <jmkasunich> yes and no ;-/
[03:50:26] <alex_joni> petev: how emc currently works, you can have 4 GUI's running at the same time
[03:50:30] <alex_joni> heck even 100
[03:50:37] <petev> I understand that
[03:50:49] <jmkasunich> you could build a GUI that goes to HAL for all it's controls, and then use HAL to connect any mix of physical and on-screen controls to it
[03:50:53] <alex_joni> so having another one (the hardware UI) that adds to the system won't matter
[03:50:55] <petev> but a button is a button and it would be nice to use the same code path
[03:51:06] <paul_c> * paul_c has run a remote GUI to control a machine in SoCal.
[03:51:09] <jmkasunich> but since 90% of folks use only on-screen controls, you are adding a lot of hal configs
[03:51:31] <SWPadnos> what if I want a tool change M-code to prompt the user to change tools?
[03:51:42] <alex_joni> it does that already
[03:51:56] <paul_c> (MSG: Change the tool Stupid)
[03:52:03] <SWPadnos> in "machine logic"?
[03:52:08] <petev> I'm not saying the GUI should only talk to the HAL if that's what you're thinking
[03:52:10] <jmkasunich> right now, tool change M code sents a bit to HAL/CL, which changes the tool
[03:52:25] <SWPadnos> yeah - and what if I don't have a toolchanger?
[03:52:33] <jmkasunich> but for manual toolchange, the tool change logic needs to send a bit/message back up to the GUI instead
[03:52:33] <alex_joni> it's a bit more complicated than that.. but yes
[03:52:47] <SWPadnos> bing! HAL, meet GUI
[03:52:49] <alex_joni> SWPadnos: for simple systems there is a stupid loopback in HAL
[03:53:00] <alex_joni> excuse the "stupid"
[03:53:05] <SWPadnos> sure - that's just a simple example (because I'm a simple machinist)
[03:53:15] <alex_joni> SWPadnos: it's not HAL meet GUI
[03:53:18] <SWPadnos> s/stupid/simple/ :)
[03:53:21] <petev> I personally would like to see flexible GUI blocks that can be configured as desired
[03:53:26] <alex_joni> it's HAL meet I/O operation
[03:53:45] <alex_joni> petev: that has absolutely no connection to the way HAL behaves or the way EMC behaves
[03:53:49] <SWPadnos> no - It's not an I/O operation, because I have to ask the operator to do domwthing, then wait for their response
[03:53:56] <SWPadnos> this is UI / GUI
[03:53:56] <alex_joni> you might want to look at HAL for the how-to do it though
[03:54:10] <SWPadnos> that's topic 2, I guess
[03:54:11] <petev> well there needs to be a defined way for these GUI blocks to talk to EMC
[03:54:23] <alex_joni> oh, it is very defined
[03:54:25] <paul_c> SWPadnos: If you are stuck with manual toolchange, you write your G-code to reflect that, and use M01 pauses.
[03:54:27] <SWPadnos> NML
[03:54:30] <jmkasunich> I have no prob with a GUI using HAL to talk to buttons, but I am reluctant to have it talk directly to the GUI, exactly because of the remote GUI issue
[03:54:32] <petev> no, it's not
[03:54:43] <alex_joni> petev: did you ever look at emcsh?
[03:54:46] <petev> I can't add a HW cycle stop/start
[03:55:01] <SWPadnos> paul_c, what if I'm running someone else's code, or testing it on my machine before sending it to someone else to produce?
[03:55:01] <alex_joni> what's a HW cycle stop/start?
[03:55:11] <petev> yes, but I think it has problems
[03:55:16] <jmkasunich> a physical button that does the cycle start function
[03:55:26] <alex_joni> so where's the problem for that?
[03:55:31] <petev> emcsh will need modification for any new IO it doesn't understand
[03:55:52] <petev> how do you connect it to EMC and make it work?
[03:56:11] <alex_joni> add a inb to the GUI?
[03:56:17] <jmkasunich> you connect the physical button to a GUI
[03:56:17] <SWPadnos> not with HAL
[03:56:22] <SWPadnos> (inb, that is)
[03:56:28] <jmkasunich> I would use HAL for that
[03:56:38] <petev> I would use HAL too, but then what?
[03:56:48] <paul_c> You're looking at the problem arse about face.. At what point is the h/w button wired in ?
[03:56:49] <jmkasunich> button -> HAL -> GUI -> NML -> task -> motion/IO
[03:57:03] <paul_c> (crap)
[03:57:12] <alex_joni> button -> HAL -> GUI -> NML -> task -> motion/IO -> HAL -> ...
[03:57:12] <petev> ok, so the GUI needs to talk to the HAL
[03:57:15] <petev> so that better be RPC
[03:57:19] <petev> or something
[03:57:23] <paul_c> h/w -> Interface code -> NML -> Task
[03:57:41] <jmkasunich> then why bother with HAL at all?
[03:57:42] <alex_joni> exactly what I was suggesting..
[03:57:55] <SWPadnos> assume that the button is on the same I/O card that all the HAL I/O is on
[03:57:57] <fenn> h/w -> magic do anything layer -> task
[03:58:03] <alex_joni> paul_c: h/w -> HAL -> emcsh similar for hal -> NML ->...
[03:58:04] <SWPadnos> you can't access it from userspace cleanly
[03:58:19] <petev> swp: what is it?
[03:58:21] <jmkasunich> you have a parport, 6 pins are step/dir, you want to use the 7th for cycle-start, gotta go thru HAL
[03:58:30] <petev> agreed
[03:58:40] <SWPadnos> it is the hardware
[03:58:44] <petev> so GUI<->HAL is via what?
[03:58:52] <alex_joni> NML
[03:58:54] <petev> RPC libhal?
[03:58:56] <jmkasunich> direct
[03:59:03] <alex_joni> but it's not GUI<->HAL
[03:59:04] <paul_c> If you use CL to connect to the h/w cycle button...
[03:59:12] <petev> alex:how do you do that and not have to keep changing code?
[03:59:25] <paul_c> You just need to send a pause message to task
[03:59:30] <jmkasunich> GUI exports a HAL pin for any controls that you want to use physical HW for, then you connect that pin to the physical device in hal
[03:59:33] <alex_joni> if you have the same functionality as in emcsh..
[03:59:49] <alex_joni> I didn't see emcsh to get changed in the last year
[03:59:59] <alex_joni> jmkasunich: yes, but not GUI
[03:59:59] <petev> johnk: i'm with you, but I want the GUI to run remote too
[04:00:05] <alex_joni> let's leave it separately
[04:00:15] <alex_joni> have one component (that works just like emcsh)
[04:00:21] <alex_joni> maybe add that part to iocontrol
[04:00:21] <jmkasunich> so run two, one remote, screen stuff only, one local that handles the physical stuff
[04:00:48] <alex_joni> jmkasunich: not that easy to add HAL pins to tcl code, or to python code
[04:00:56] <petev> jmk: I don't follow, how is a remote SW cycle stop/start handled?
[04:01:09] <jmkasunich> SW as in a widget on screen?
[04:01:13] <petev> yes
[04:01:15] <alex_joni> petev: like it was always handled.. through NML
[04:01:23] <jmkasunich> user clicks widget, the GUI that owns the widget sends NML
[04:01:48] <petev> alex: then a SW button is not the same path as a HW button, bad idea to me
[04:02:00] <alex_joni> why?
[04:02:05] <alex_joni> it is the same path
[04:02:12] <alex_joni> button gets to NML
[04:02:17] <alex_joni> NML gets to task, etc
[04:02:19] <petev> different paths in code = possibly different behavior
[04:02:32] <jmkasunich> we already support multiple GUIs, what is wrong with one that is running remote and uses widgets and another running local using physical I/O?
[04:02:38] <alex_joni> if you have different GUI's you'll have different paths in code
[04:03:01] <petev> no, GUI is not supposed to have state
[04:03:09] <petev> it just tells EMC and reflects state
[04:03:11] <jmkasunich> yeah, you can run mini on one box, and tkemc on another (or several instances of each one on the same box at the same time, if you are perverse ;-)
[04:03:31] <alex_joni> petev: wth did state come from now?
[04:03:39] <petev> about two GUI
[04:03:49] <alex_joni> still don't get it
[04:03:49] <petev> still the same path if state is not in GUI
[04:03:59] <alex_joni> path= state?
[04:04:04] <alex_joni> you completely lost me now..
[04:04:11] <jmkasunich> me too
[04:04:14] <petev> each GUI tells HAL, same path through EMC
[04:04:16] <SWPadnos> the state is in trhe NML status buffer(s)
[04:04:19] <SWPadnos> the
[04:04:22] <paul_c> Hey guys. Shut up for a moment.
[04:04:31] <petev> not much chance for different behavior if GUI is stateless
[04:04:34] <jmkasunich> HAL is not involved in GUI <-> task comms
[04:04:46] <jmkasunich> that is pure NML
[04:04:56] <alex_joni> * alex_joni shuts it
[04:05:00] <SWPadnos> yes, paul_c ?
[04:05:03] <petev> jmk: then you are saying a SW button is different that a HW button
[04:05:05] <jmkasunich> HAL would only be used to connect pendant controls or such to GUI
[04:05:10] <jmkasunich> * jmkasunich shuts up
[04:05:16] <fenn> OBEY!
[04:05:40] <paul_c> GUI widget sends a Pause or Start message
[04:05:56] <paul_c> GUI reads back Status message from the controlling Task
[04:06:01] <jmkasunich> NML messages
[04:06:10] <alex_joni> whatever messages.. not important
[04:06:12] <paul_c> There is NO state logic within the GUI.
[04:06:18] <jmkasunich> exactly
[04:06:33] <fenn> glad we can all agree on something
[04:06:36] <paul_c> You can issue a Pause message from one GUI
[04:06:39] <alex_joni> so any GUI sends a NML message, ALL the other GUI's get the status
[04:06:40] <SWPadnos> only race conditions
[04:06:44] <jmkasunich> (although the message sent depends on the state that it got from EMC)
[04:06:55] <paul_c> and a second GUI will echo the state when it changes in task.
[04:07:00] <jmkasunich> right
[04:07:02] <petev> then SW button is different than HW button and they cannot be interchanged for debug, etc.
[04:07:21] <alex_joni> any SW button needs to act exactly like a HW button
[04:07:23] <paul_c> petev: IF you let me finish
[04:07:33] <petev> ok, sorry
[04:08:26] <fenn> hrm.. jymm you know how to use that thing?
[04:08:27] <paul_c> There is no reason why you couldn't code a layer between CL and the NML command messages
[04:08:55] <paul_c> so that you could "wire" a h/w button to the NML pause messgae
[04:09:30] <petev> paul: so they are only the same from NML on
[04:09:40] <petev> what if I want to test a HAL component?
[04:09:40] <paul_c> Press the button, an NML message is sent to task
[04:10:01] <alex_joni> may I say something now?
[04:10:18] <paul_c> If you want to "plug in " HAL, talk to JMK
[04:10:33] <alex_joni> this whole thing is not about NML nor HAL..
[04:10:44] <paul_c> My point is - It does not matter where the NML messages are sent from.
[04:11:04] <alex_joni> the main thing is: you have a lot of UI's (some software GUI's and some Hardware UI's)
[04:11:11] <alex_joni> and they all need to cooperate
[04:11:18] <jmkasunich> yes
[04:11:22] <petev> agreed
[04:11:26] <alex_joni> that only works if you have task taking care of states & the like
[04:11:32] <paul_c> and you certainly do not want to, or need to route HAL pins & signals all the way up to the GUI level.
[04:11:33] <alex_joni> like it does now..
[04:11:35] <petev> agreed
[04:11:57] <alex_joni> ok.. so besides the GUI's that exist now, what I see missing is a hardware panel
[04:12:02] <alex_joni> a hardware UI
[04:12:04] <petev> paul: no, but you may want to route a SW button down to HAL
[04:12:06] <jmkasunich> yeah
[04:12:23] <jmkasunich> dammit - I was saying yeah to alex
[04:12:28] <alex_joni> the software component doing that will simply send NML messages like any other GUI's
[04:12:35] <paul_c> petev: no I would not.
[04:12:45] <SWPadnos> um - that assumes that there is not now, nor will there ever be, a reason to have a GUI that can be used in place of hardware.
[04:12:46] <alex_joni> and it WILL get status messages, and behave like any other GUI
[04:12:58] <petev> paul: assume you are ok with HAL for a momemt, then why not?
[04:12:59] <jmkasunich> pete: if you simply want to twiddle a HAL pin with a screen widget, you can do that without involving EMC or NML at all
[04:13:30] <alex_joni> SWPadnos: my goal is to have a GUI that can be used either as pure SW or as pure HW, or anywhere inbetween
[04:13:49] <petev> agreed
[04:13:55] <alex_joni> jmkasunich: but EMC will have no way to know about that
[04:14:00] <SWPadnos> it's not just the UI that's a problem, it's that you may want to "simulate" parts of a machine as well
[04:14:19] <petev> yes
[04:14:23] <alex_joni> SWPadnos: like user(operator) brains
[04:14:34] <petev> or limits during testing, etc.
[04:14:49] <SWPadnos> you could do waterline milling without a powered Z axis - pop up a dialog asking the user to plunge 0.020
[04:14:57] <alex_joni> petev: that's part of halgui.. and the integrator to take care
[04:15:15] <petev> alex:halgui? what's that?
[04:15:29] <alex_joni> * alex_joni suggest reading about it ;)
[04:15:32] <alex_joni> or what it should be..
[04:15:38] <SWPadnos> CrapaHALic!!!
[04:15:42] <SWPadnos> sorry
[04:16:25] <fenn> alex_joni: what does crapahalic have to do with it?
[04:16:42] <SWPadnos> e.g. changing limits during testing
[04:17:13] <petev> swp: why? I would like to test my homing before I connect the belts
[04:17:15] <alex_joni> fenn: it's what petev wants for altering the HAL stuff
[04:17:33] <SWPadnos> that was a reply to fenn about the usefulness of HalGUI
[04:17:39] <petev> oh
[04:17:59] <SWPadnos> I agree - you should test homing :)
[04:18:32] <jmkasunich> I test homing by setting home_search_vel to 0.01 ;-)
[04:18:51] <jmkasunich> (sorry, irrelevant)
[04:19:39] <jmkasunich> pete and I both want to be able to toss widgets on the screen and use them to twiddle HAL pins
[04:19:45] <petev> agreed
[04:20:04] <jmkasunich> but I don't see the need for RPC
[04:20:08] <SWPadnos> and possibly have HAL pins cause widgets to be displayed
[04:20:34] <Jymmm> SWPadnos "to be displayed" or "to change state/condition" ?
[04:20:39] <jmkasunich> IOW: have widgets that display the state of hal pins
[04:20:40] <SWPadnos> either
[04:21:02] <SWPadnos> again - I'm thinking of the "user as aprt of machine" scenario
[04:21:05] <SWPadnos> part
[04:21:16] <petev> jmk: RPC is simply to allow remote operation, I personnaly don't care because X works fine, but it seemed like an issue for others
[04:22:09] <alex_joni> petev: so basicly you want some GUI bits (widgets) that export HAL pins, and you shuffle them together and you get a fancy version of TkIO ?
[04:22:19] <Jymmm> * Jymmm has run TkEMC on Win2K remotely and another gui on the main box... works nicely.
[04:22:24] <jmkasunich> alex: that is what I have in mind
[04:22:48] <petev> jymmm: that's fine if you are happy with the control tkemc offers
[04:23:06] <Jymmm> petev then change it to fit your needs
[04:23:22] <alex_joni> jmkasunich: but that's got NOTHING to do with emc
[04:23:29] <jmkasunich> I know ;-)
[04:23:31] <alex_joni> even if I like it or find it cool
[04:23:34] <paul_c> Jymmm: You could probably run mini too... and with a little effort, axis.
[04:23:36] <Jymmm> I edot it to use a pseudo pendant
[04:23:38] <jmkasunich> the other half of it does though...
[04:24:14] <jmkasunich> I also want a UI (not neccessarily GUI) that reads HAL pins instead of (or in addition to) the keyboard/mouse, and writes HAL pins instead of the screen
[04:24:22] <Jymmm> paul_c Yeah, but I couldn't edit all the gui's to do the pseudo pendant =)
[04:24:26] <jmkasunich> it would still speak NML on the EMC side, but HAL on the user side
[04:24:41] <jmkasunich> then I can connect either hardware or on-screen controls to it
[04:25:39] <jmkasunich> that would simply be one of the available UIs, use it, or tkemc/mini/axis, or any combination that float your boat
[04:25:42] <alex_joni> jmkasunich: hmm.. this would then be like:
[04:25:58] <alex_joni> GUI (tkemc,mini,axis,..) -> NML -> task
[04:26:32] <alex_joni> HAL UI(some sttuff petev does) -> HAL -> iocontrol -> NML -> task
[04:26:41] <jmkasunich> nope
[04:26:42] <alex_joni> actual hardware -> HAL -> iocontrol -> NML -> task
[04:26:50] <alex_joni> well.. iocontrol is not the best name
[04:26:58] <alex_joni> although I think it can do both directions
[04:27:04] <jmkasunich> HW button -> new halish UI -> NML -> task
[04:28:04] <fenn> do you write new drivers for that button?
[04:28:12] <alex_joni> what's wrong with the other approach?
[04:28:13] <jmkasunich> the NML messages sent by this new halish UI would be the same as sent by the other GUIs, not the ones that go back and forth to iocontrol
[04:28:19] <alex_joni> fenn: or use existing..
[04:28:19] <SWPadnos> no - that's why the UI-ish thing speaks HAL
[04:28:46] <lerman> rayhExactly. And we are all entitled to start a branch and contribute what we think will make it so.
[04:28:48] <lerman> rayhI'm already pissed that lerman-interp can't keep up with hal changes.
[04:28:50] <lerman> And there's the problem. Anyone can start a branch, but who determines what gets into the main line?
[04:28:55] <jmkasunich> more accurately: HW button -> some HAL driver -> HAL signals -> halish UI -> NML -> task
[04:28:57] <petev> yes, all UI command should go to the same place, task
[04:29:19] <lerman> Sorry to change topics on you guys --feel free to ignore it until you get a chance to comment.
[04:29:20] <SWPadnos> lerman, the board? (once it's elected)
[04:29:28] <alex_joni> jmkasunich: right, but the halish UI doesn't need to be a GUI
[04:29:37] <lerman> Well, there is already a board -- the old one.
[04:29:51] <jmkasunich> alex: true
[04:29:52] <alex_joni> then I agree completely, and it's actually the same thing as I tried to state above
[04:30:02] <jmkasunich> we tend to use GUI and UI interchangably
[04:30:22] <jmkasunich> but its not the same as using iocontrol
[04:30:28] <lerman> The board should determine the general criteria in such a way that one can know (or at least guess) before hand whether one's work will be accepted and merged.
[04:30:37] <petev> ok, so then we just don't get HAL widgets until we write halgui
[04:30:42] <petev> that's fine
[04:30:45] <jmkasunich> the NML vocabulary for UI <-> task and task <-> iocontrol are different
[04:31:08] <petev> so how do we fix the NML messages so that we don't have to add new ones for every little thing?
[04:31:09] <alex_joni> yes, but they can be handled by the same component
[04:31:19] <alex_joni> petev: use generic ones
[04:31:28] <petev> there are none now
[04:31:35] <petev> are we going to make new ones?
[04:32:01] <alex_joni> * alex_joni just added a NML message the other day
[04:32:05] <alex_joni> took about .5 minutes
[04:32:05] <jmkasunich> alex: why combine I/O related stuff with UI stuff?
[04:32:31] <alex_joni> jmkasunich: to limit the number of the running processes ?
[04:32:39] <petev> ok, so walk me through mapping of a HAL button to an NML message? where does this take place? Is it hard coded?
[04:32:56] <jmkasunich> alex: not much of a reason ;-)
[04:33:02] <alex_joni> * alex_joni is fine with having yet another program doing that.. but lots of code would be duplicated (mainly ini,NML config stuff)
[04:33:42] <paul_c> alex_joni: Tip: Use a shared library for common code.
[04:33:56] <jmkasunich> petev: this new halish UI would have HAL pins for the various messages that a UI might send
[04:34:09] <jmkasunich> you connect (in HAL) buttons to the ones you want to send
[04:34:16] <jmkasunich> press the button, the message gets sent
[04:34:22] <petev> so you're saying the mapping is hard coded
[04:34:27] <petev> I would like to avoid that
[04:34:39] <jmkasunich> the NML messages themselves are hard coded
[04:35:00] <jmkasunich> the mapping is variable, by hal signals
[04:35:09] <jmkasunich> button to pin connections that is
[04:35:14] <paul_c> ffs.. Somewhere along the line, you will need to write SOME code.
[04:35:16] <jmkasunich> pin to message is hard-coded
[04:35:46] <petev> ok, so halui will need to be changed for every new feature that requires a new NML message
[04:35:59] <Jymmm> jmkasunich "hard-coded"
[04:36:00] <Jymmm> ?
[04:36:01] <jmkasunich> so will all the GUIs
[04:36:16] <alex_joni> petev: add the current rate of new features added.. not a problem
[04:36:18] <petev> well, I was getting to that with the GUI blocks
[04:36:21] <alex_joni> not even a concearn
[04:36:38] <jmkasunich> right now, there is code somewhere in every GUI that says "when the button at the top left of my window is clicked, send the following NML message"
[04:36:48] <alex_joni> what was the last GUI related feature added?
[04:36:57] <alex_joni> does anyone know?
[04:37:12] <jmkasunich> the halish one would say "when hal pin such-and-such changes state, send the following NML message"
[04:37:13] <paul_c> Notepad style editor to mini
[04:37:16] <petev> I have a list of GUI features I would like to see
[04:37:23] <paul_c> before that, a 3D backplotter
[04:37:24] <alex_joni> paul_c: involving NML
[04:37:25] <jmkasunich> you get to decide what button toggles that pin
[04:37:35] <paul_c> (this discounts Axis)
[04:37:37] <petev> jmk:understood
[04:37:49] <SWPadnos> petev, can you add them to one or more trackers?
[04:38:10] <petev> sure
[04:38:16] <petev> from Mesa
[04:38:19] <petev> On Fri, 18 Nov 2005, Peter G. Vavaroutsos wrote:
[04:38:19] <petev> > Peter, I know you gave the ok to post the FPGA code on Source Forge with the
[04:38:20] <petev> > EMC driver, but some of the guys are upset that the files don't have a GPL
[04:38:21] <petev> > license header. I didn't add one as I didn't think it was a big deal. Do you
[04:38:21] <petev> > object to having GPL headers added or would you like the files removed from
[04:38:21] <SWPadnos> thanks
[04:38:21] <petev> > Source Forge? Please advise.
[04:38:23] <petev> I have no problem with adding the GPL headers, go ahead....
[04:38:33] <SWPadnos> cool - thanks
[04:38:39] <alex_joni> petev: sounds great.. wasn't that hard ;)
[04:38:50] <jmkasunich> alex: maybe one fact (no GUI changes recently) relates to the other (new NML messages need to have all GUIs updated to take advantage of them)
[04:38:51] <SWPadnos> I was just looking through that archive, and there's not a lot of (VHDL) source in there anyway
[04:38:53] <paul_c> Fortunately, there are only a limited number of messages that the HMI needs to send to task.
[04:40:07] <paul_c> petev: suggest you add a copy of that email (including headers) to the VHDL directory.
[04:40:37] <paul_c> That would cover our (collective) arses.
[04:41:06] <paul_c> copyright laws suck, and the direction the USA is going, it will only get worse.
[04:42:28] <fenn> i'm going to bed.. hope you guys can talk about something constructive
[04:43:02] <jmkasunich> lets get back to the UI thing, the VHDL issue can be dealt with by one or two people at most
[04:43:44] <alex_joni> jmkasunich: the last stuff I've seen that involves GUI & NML is in tkemc/emcsh (adding EMC_SET_DEBUG)
[04:43:45] <jmkasunich> I have an interesting example to discuss
[04:43:50] <alex_joni> and it happened .. 4 years ago
[04:43:53] <paul_c> jmkasunich: The VHDL issue has been delt with - I was suggesting a method for final closure.
[04:44:15] <jmkasunich> I agree that a copy of the email should be saved in CVS
[04:44:25] <alex_joni> jmkasunich: to be precise Fri Jun 1 18:31:06 2001 UTC (4 years, 5 months ago) by proctor
[04:44:26] <SWPadnos> I was just pointing out that there's not a lot of IP in that archive - it's essentially "binaries" for the FPGA
[04:44:42] <SWPadnos> not a lot of source IP, that is
[04:44:49] <petev> SWP: no, the VHDL is in there too
[04:44:55] <jmkasunich> done, dead issue, back to topic please!
[04:45:08] <SWPadnos> ok - we can discuss later
[04:45:21] <jmkasunich> interesting example:
[04:45:31] <jmkasunich> the mazak has a button called "tool unclamp"
[04:45:39] <jmkasunich> it releases the drawbar
[04:46:15] <jmkasunich> we used a physical button, because you'll be catching the tool with one hand and pushing the button with another, hard to do with a mouse and eyes on the screen
[04:46:28] <jmkasunich> but it could have been on screen to, irrelevant right now
[04:46:32] <alex_joni> or even with the PC 10 feets away
[04:46:35] <paul_c> Use a touch screen
[04:46:40] <jmkasunich> the GUI and EMC know nothing about that button
[04:46:57] <SWPadnos> remote control
[04:47:01] <jmkasunich> we're running it into HAL, thru a CL rung to make sure you don't release the tool while the spindle is on, and out to the actuator
[04:47:18] <paul_c> Does the GUI need to know about the button ?
[04:47:23] <jmkasunich> question: should EMC know about that?
[04:47:32] <SWPadnos> I've heard that before :)
[04:47:34] <paul_c> No
[04:47:34] <jmkasunich> paul_c: you anticipated my question
[04:48:04] <SWPadnos> should it restart the cycle when it knows there's no tool (or the drawbar is "up")?
[04:48:09] <Jymmm> jmkasunich: Doe sthe GUI need to know it's status?
[04:48:11] <jmkasunich> no imaginable reason for EMC to know?
[04:48:17] <paul_c> The GUI's primary purpose is to display position and provide a means to load and run a file.
[04:48:50] <SWPadnos> sure, but you can also do nice things like disable the "cycle start" or "run" buttons if you know ther machine isn't "ready" to run
[04:48:53] <paul_c> Beyond that, anything else is eye candy.
[04:49:01] <jmkasunich> and to jog, and initiate homing, and do a bunch of other things (when in manual mode)
[04:49:33] <paul_c> MDI functions are secondary.
[04:49:49] <paul_c> Useful, agreed.
[04:50:17] <SWPadnos> My personal choice would be for the GUI to be able to show all aspects of machine state
[04:50:19] <jmkasunich> nobody is gonna want to run a machine that doesn't have manual and MDI control
[04:50:27] <SWPadnos> and ideally to be able to do that remotely
[04:50:43] <jmkasunich> another example:
[04:50:55] <jmkasunich> you can raise and lower the mazak's head
[04:51:08] <jmkasunich> no encoder, just up and down buttons (AC gearmotor)
[04:51:11] <paul_c> For people that dislike soft-buttons, perhaps some means of connecting physical h/w buttons to specific NML messages is required.
[04:51:24] <jmkasunich> you have to touch off or otherwise re-establish coordinates after moving it
[04:51:39] <alex_joni> doesn't encoder get tracked?
[04:51:40] <jmkasunich> should EMC know when you move it?
[04:51:43] <paul_c> For example, Abort, Jog, Home, Axis select.
[04:51:49] <jmkasunich> alex: there is no encoder on that axis
[04:51:59] <alex_joni> add one ;)
[04:52:20] <alex_joni> it probably should know..
[04:52:43] <alex_joni> _I_ would hook it up to the HAL UI stuff, and let it run through NML, task and motion
[04:52:50] <jmkasunich> well Mazak and Fanuc didn't think it important
[04:53:06] <SWPadnos> you re-zero the toolheight anyway after moving the head
[04:53:13] <jmkasunich> right
[04:53:24] <alex_joni> doesn't it involve security issues?
[04:53:25] <Yuga> any one have any idea where i would be able to buy a surface mounted tempreture sensor?
[04:53:32] <paul_c> rig up an encoder and call it axis W
[04:53:33] <alex_joni> the head lowered might get in the way?
[04:53:44] <jmkasunich> we planned (and still do) to run the head controls thru HAL only, no connection to EMC
[04:53:46] <SWPadnos> Digi-Key
[04:53:50] <paul_c> Yuga: Texas Instruments
[04:54:26] <Yuga> paul_c... do they have a online shop?
[04:54:33] <paul_c> surface mount as in bolt to heatsink, or as in SM package ?
[04:54:55] <jmkasunich> paul_c: can't make it a controlled axis - it is powered by a 60Hz three phase motor with a reversing contactor
[04:54:58] <SWPadnos> what temperature rnage?
[04:55:04] <jmkasunich> one speed up, one speed down, and stop
[04:55:12] <SWPadnos> it can be controlled, but not for speed
[04:55:15] <Yuga> 60 and 70
[04:55:17] <SWPadnos> like a spindle
[04:55:20] <SWPadnos> C?
[04:55:27] <Yuga> need it to controle a fan sothat my amps dont burn out
[04:55:32] <jmkasunich> not for pseed or position
[04:56:11] <jmkasunich> I've seen temp switches in TO-220 packages
[04:56:23] <jmkasunich> connect directly to fan to turn it on or off
[04:56:23] <Yuga> ?
[04:56:28] <SWPadnos> what supply voltage?
[04:56:35] <jmkasunich> (but I'd just let the fans run all the time)
[04:56:40] <paul_c> Yuga: Thermistor - Take a look at some of the case fans for desktop PCs. Some of them have a temp. sensor.
[04:56:48] <SWPadnos> yeah - me, too. run the fans all the time
[04:57:42] <Yuga> well it's going to be used to run the fan... and as a shut off it it reaches 90
[04:57:51] <paul_c> jmkasunich: Just having feedback from a W axis does not mean it has to be under the control of motion.
[04:57:57] <jmkasunich> understood
[04:58:06] <SWPadnos> http://www.digikey.com/scripts/DkSearch/dksus.dll?Detail?Ref=297934&Row=360977&Site=US
[04:58:17] <paul_c> motion can use the feedback to apply ofsets to Z
[04:58:30] <jmkasunich> but in this case, feedback and control are both overkill, and involve machine changes that many folks won't want to bother with
[04:58:41] <jmkasunich> same applies to Bports with CNC quill and manual knee
[04:58:57] <SWPadnos> tell me about it ;)
[04:59:04] <jmkasunich> sure, you could put an encoder or glass scale on the knee and use it to offset Z, but how many folks actually do that?
[04:59:12] <SWPadnos> Ron Rogers
[04:59:19] <SWPadnos> (I think)
[04:59:23] <paul_c> and some Bridgeports have scales on the knee.
[05:00:33] <jmkasunich> and some do not
[05:00:45] <SWPadnos> I have one of the latter type
[05:00:57] <jmkasunich> so we make it possible for the user to touch off and establish offsets
[05:01:21] <jmkasunich> my question was about whether EMC should know or care about the head being moved
[05:01:44] <SWPadnos> possibly - it should brobably stop milling if the head is moved
[05:01:47] <jmkasunich> if not, we can easily do it in HAL (and can even interlock, so they can't move it while amps are enabled, for example)
[05:01:48] <SWPadnos> probably
[05:02:07] <SWPadnos> but you want to pause task as well
[05:03:08] <jmkasunich> ok, so now we have an example of something that might want to get into EMC, but that the existing NML messages might not cover
[05:03:28] <jmkasunich> how do we do it?
[05:03:47] <Yuga> does any one know the standard measurments for a rack mounted item? i have looked on about 6 sites and i get different measurments from each one
[05:03:54] <SWPadnos> I think Paul mentioned some "generic NML Message" warlier
[05:04:07] <jmkasunich> new GUI -> task message, new iocontrol -> task message?
[05:04:30] <paul_c> interlock to prevent movement of the head (or W axis) is specific to that particular machine, and could prpbably be solved via CL.
[05:04:39] <jmkasunich> it would be in CL
[05:05:06] <paul_c> right, so you have the bandaids in place already
[05:05:53] <jmkasunich> if the up and down buttons are physical, then those sigs go: button -> I/O driver -> HAL -> CL interlock -> HAL -> I/O driver -> contactor
[05:06:29] <paul_c> so no need to add to the NML structures.
[05:06:30] <SWPadnos> but that gives the GUI no indication that it should stop, or tell the operator that the head is in motion
[05:06:32] <jmkasunich> if the buttons are on screen, I want them to go: button widget -> HAL -> CL interlock -> HAL -> I/O driver -> contactor
[05:07:24] <paul_c> right, so it still isn't my problem.
[05:07:32] <jmkasunich> if the GUI and/or task needs to know, that is where it gets interesting
[05:08:32] <paul_c> if your widget is part of the GUI, the code is in place for you to work round the usr side.
[05:08:32] <SWPadnos> and if you have things that go task -> HAL -> CL -> HAL -> hardware driver(s) -> Hardware
[05:08:41] <SWPadnos> and you want to have the user do those things
[05:09:06] <paul_c> IF you need to talk to task on a key event, you need to define what data is to be passed.
[05:09:34] <SWPadnos> I'm stuck on toolchanges at the moment
[05:09:42] <paul_c> and then define what actions are taken by task when the message is recieved.
[05:09:50] <SWPadnos> task asks for a tool, I have no automatic changer, I want a prompt instead
[05:10:12] <jmkasunich> today, you get a HAL pin coming out of iocontrol that goes TRUE
[05:10:30] <jmkasunich> and another one (an integer) with the desired tool number
[05:10:31] <alex_joni> connect that to petev's GUI
[05:10:49] <jmkasunich> emc will wait until another pin goes TRUE telling it that the change is complete
[05:10:56] <jmkasunich> you want to get from there to the screen, right?
[05:11:27] <SWPadnos> I want to have the screen be between the bit/integer, and the "done" bit, yes
[05:11:43] <paul_c> Connect the CL pin to a hardware relay. Use the relay to turn on an FO klaxon
[05:11:52] <jmkasunich> lol
[05:12:04] <SWPadnos> that might work ;)
[05:12:07] <SWPadnos> *without* task or iocontrol being modified for this purpose
[05:12:08] <alex_joni> yeah.. 140 dB minimum
[05:12:27] <paul_c> problem solved. I can go to bed.
[05:12:41] <alex_joni> or maybe use a few relays to turn on coloured lightbulbs
[05:12:43] <SWPadnos> they shouldn't know that the toolchanger is a person, just as it's unmimportant whether the toolchanger is a carousel or a set of table pockets
[05:12:50] <jmkasunich> you want to pop up a dialog when the first HAL pin goes true, displaying the tool number, and a DONE button
[05:12:56] <SWPadnos> exactly
[05:13:01] <jmkasunich> when they hit the button, it sets the other pin true
[05:13:09] <SWPadnos> (or "move Z down 0.020")
[05:13:26] <SWPadnos> but not for toolchanges, obviously
[05:13:32] <alex_joni> SWPadnos: the first case is easy handled by G-code
[05:13:39] <alex_joni> the second one not that easily
[05:14:11] <SWPadnos> the first case shouldn't require any different G-code than that for a machine *with* a toolchanger
[05:14:24] <alex_joni> * alex_joni goes to bed..
[05:14:32] <alex_joni> darn discussion ;) it's 5am
[05:14:38] <SWPadnos> sorry - good night :)
[05:14:52] <alex_joni> wanted to do some work tomorrow.. now I'll have to recover :D
[05:14:52] <SWPadnos> the point is, the user *is* the toolchanger, and there's no reason why task or iocontrol should have to know that
[05:14:55] <jmkasunich> right - that means the thing that pops up the dialog should connect directly to HAL, and "pretend" to be a toolchanger
[05:15:05] <SWPadnos> it *is* the toolchanger :)
[05:15:07] <alex_joni> SWPadnos: what jmk said
[05:15:20] <SWPadnos> :P
[05:15:23] <SWPadnos> night
[05:15:26] <alex_joni> so a simple container with a button and 2 HAl pins?
[05:15:36] <alex_joni> ahh.. and a message
[05:15:37] <jmkasunich> three - one for the tool number
[05:15:46] <jmkasunich> so the message needs to change based on the number
[05:16:02] <alex_joni> ok.. pretty specific widget
[05:16:04] <SWPadnos> but the bigger question is how does the HAL pin get to/from the GUI software?
[05:16:05] <jmkasunich> hard to genericize that
[05:16:12] <alex_joni> jmkasunich: got my private /msg?
[05:16:24] <SWPadnos> Sure - the widget set has to be written (could be QT / RAD stuff)
[05:16:25] <jmkasunich> back up a sec SWP
[05:16:39] <jmkasunich> alex: about the runaway thing?
[05:16:43] <alex_joni> yup
[05:16:58] <jmkasunich> got it, don't know what you want me to do/say
[05:16:59] <djb_rh> so, how does one find out of the DC servos and the encoders on this mill: http://gallery.donniebarnes.com/cnc-mill can be run by any EMC compatible controller?
[05:17:01] <SWPadnos> ?erawtfs IUG eht morf/ot teg nip LAH ...
[05:17:12] <alex_joni> hope the fix was ok, I did look at other ways to fix it..
[05:17:27] <djb_rh> tag info from the encoders and motors can be found at: http://www.donniebarnes.com/~djb/mill-info.txt
[05:17:28] <alex_joni> but I think it was a rounding error that caused the axis to run away
[05:17:28] <Jymmm> Couldn't an ACTUAL toolcharger (and it's parameters) be in a configuration somewhere, with a pseudo (human) toolchanger being one of hte options?
[05:17:32] <SWPadnos> figure out what kind of input the drivers need
[05:17:35] <jmkasunich> I never even had a chance to look a tit
[05:17:42] <jmkasunich> at it ;-)
[05:17:45] <SWPadnos> I like to look a tit :)
[05:17:45] <alex_joni> lol
[05:18:12] <alex_joni> jmkasunich: I did put some halmeters (even halscope) to look a tit
[05:18:25] <alex_joni> but it seemed the commanded position was equal feedback..
[05:18:27] <SWPadnos> well - have a tit, it's bedtime
[05:18:38] <jmkasunich> goodnight alex ;-)
[05:18:45] <alex_joni> so probably an iteration problem combined with a rounding problem
[05:18:46] <SWPadnos> while you're a tit, could you ...
[05:18:51] <SWPadnos> (this could go on for a long time)
[05:19:18] <alex_joni> ok.. I'm out.. n8
[05:19:22] <djb_rh> would you people quit talking about tits and answer my question? :)
[05:19:23] <SWPadnos> are you a tit still? go to bed!
[05:19:25] <alex_joni> will read the logs later
[05:19:28] <Jymmm> SWPadnos: Here ya go... http://static.flickr.com/22/34423227_1e657046a7_m.jpg
[05:19:50] <Jymmm> SWPadnos take two, they're free.
[05:19:58] <SWPadnos> In the immortal words of Kate, "It's not natural"
[05:20:17] <SWPadnos> she's like the Grinch's heart - a few sizes too big :)
[05:20:19] <jmkasunich> djb_rh: you're asking a non-trivial question, right in the middle of a couple of ongoing conversations
[05:20:26] <djb_rh> yeah, I know
[05:20:27] <djb_rh> sorry
[05:20:28] <SWPadnos> figure out what kind of input the drivers need
[05:20:28] <jmkasunich> (sorry about the tit stuff)
[05:20:31] <djb_rh> they seemed to be wrapping up
[05:20:32] <djb_rh> :)
[05:20:40] <djb_rh> oh, the tit stuff didn't bother me
[05:20:57] <SWPadnos> they rarely do :)
[05:20:57] <djb_rh> I'm just a bit frustrated at trying to find EMC info
[05:21:02] <jmkasunich> do you have drives? or are you looking for advice about what drives to use?
[05:21:11] <djb_rh> seems there's a lot more support than we have listed
[05:21:18] <djb_rh> I have a complete CNC mill
[05:21:23] <SWPadnos> if the drivers can take either step/direction, PWM, or analog input, then they can be used with EMC
[05:21:24] <djb_rh> it's just that the PC part is circa 1985
[05:21:31] <djb_rh> and isn't worth trying to get working again
[05:21:49] <jmkasunich> SWP: we'll get back to your tookchanger GUI in a minute, don't go away
[05:21:52] <djb_rh> and I want to know if I should try to keep the motors and encoders and just get a new controller to drive them
[05:21:56] <SWPadnos> jmk - take a look - there are 3 drives in the cabinet, but I can't identify them from the low-res photos
[05:22:06] <djb_rh> or if I should replace those, too, and start much more from scratch
[05:22:07] <SWPadnos> no problem (unles sI see a tit :) )
[05:22:40] <SWPadnos> do you have hogher resolution photos available?
[05:22:43] <jmkasunich> those boxes labeled NC400 look like the drives
[05:22:44] <SWPadnos> higer
[05:22:45] <SWPadnos> higher
[05:23:09] <jmkasunich> google them, or the manufacturer (I assume there is fine print we can't read) and get data
[05:23:20] <djb_rh> I do have higher res pics
[05:23:21] <djb_rh> sorry
[05:23:23] <jmkasunich> then we can try to figure out if EMC can control the drives
[05:23:29] <djb_rh> don't know why it resized them down
[05:23:40] <djb_rh> don't forget: http://www.donniebarnes.com/~djb/mill-info.txt
[05:23:47] <djb_rh> that's most of the info from the encoder and motor tags
[05:23:57] <jmkasunich> no info about drives there, just motors and encoders
[05:24:03] <djb_rh> oh
[05:24:06] <djb_rh> then what is a "drive"?
[05:24:19] <SWPadnos> the black boxes in the controls cabinet
[05:24:36] <jmkasunich> photo 4, labeled NC400
[05:24:52] <jmkasunich> they take a control signal (maybe +/-10V) and control the power to the motors
[05:24:55] <SWPadnos> the cabinet looks prety clean, so I'd use that stuff if you can (though I'm no expert there)
[05:25:06] <djb_rh> yeah, those say "NC 400 DC SERVO CONTROLLER"
[05:25:18] <jmkasunich> look them up, get manuals
[05:25:53] <djb_rh> 10-4
[05:25:56] <SWPadnos> the motors can be controlled with several other drives, so you'll definitely be able to use them if you choose
[05:25:57] <jmkasunich> it would probably cost at least $150-200 each to replace them with something differnet, so you really would like to use them if they are in OK condition and compatible with EMC
[05:26:15] <djb_rh> interesting
[05:26:20] <djb_rh> I didn't even know that was an option
[05:26:24] <djb_rh> I assumed I'd have to replace all that
[05:26:29] <SWPadnos> also, the motors will be roughly $650 - $1000 (each) to replace with new equivalents
[05:26:32] <jmkasunich> but as SWP says, you can definitely buy new drives that will run those motors
[05:26:36] <djb_rh> but I couldn't even find good info on what would drive DC Servos
[05:26:42] <djb_rh> and be EMC compat
[05:26:46] <djb_rh> what about the encoders?
[05:26:48] <SWPadnos> I'd try to use anything you can :)
[05:26:54] <Jymmm> http://66.102.7.104/search?q=cache:_VmsfYcQ-mUJ:cgi.ebay.com/ws/eBayISAPI.dll%3FViewItem%26item%3D7549701062%26category%3D78191+NC+400+DC+SERVO+CONTROLLER&hl=en
[05:26:57] <djb_rh> well yeah
[05:27:02] <SWPadnos> the encoders are fine (and included in the servo price I mentioned)
[05:27:05] <petev> I think the drives are made by contraves
[05:27:12] <jmkasunich> they will probably work as well, but again, can't tell much just from the part number. Need to get a datasheet
[05:27:18] <SWPadnos> it looks like they're 250 CPR, or 1000 counts per revolution
[05:27:32] <SWPadnos> I have a slightly different BEI model on my motors
[05:27:34] <petev> http://www.contraves.co.uk/
[05:27:44] <jmkasunich> but details like supply voltage and pinout come from the data sheet
[05:28:00] <djb_rh> the motors said Contraves on them, too, but had a Charlotte, NC address on them
[05:28:20] <jmkasunich> first step for any project like this is to collect all the data you can get your hands on
[05:28:32] <jmkasunich> google is your friend ;-)
[05:28:32] <SWPadnos> then start letting smoke out :)
[05:29:21] <djb_rh> damn, that eBay link looks just like the rack in my machine
[05:29:25] <jmkasunich> many servo drives (also referred to as servo amps) takes +/- 10V inputs... there are several cards that you can install in a PC and use with EMC to work with that
[05:29:26] <djb_rh> interesting
[05:29:46] <jmkasunich> ebay rack = spares ;-)
[05:30:24] <djb_rh> shit, I'd go grab the manuals that came with it (which I'm sure are incomplete, but who knows?), but the wife isn't home yet and the kids are in bed
[05:30:31] <djb_rh> the shop is a golf kart ride away
[05:30:39] <petev> if you can't find info, you can always buy a repair manual, looks like you have a BOSS 8
[05:30:41] <djb_rh> she should be home soon
[05:31:00] <jmkasunich> better to read the manuals a little, and post questions to the users list
[05:31:16] <djb_rh> jmkasunich: ah, didn't know that
[05:31:20] <jmkasunich> these are non-trivial things to answer, there isn't too much we can do on the spot like this
[05:31:25] <djb_rh> gotcha
[05:31:29] <djb_rh> I didn't expect miracles
[05:31:31] <djb_rh> just pointers
[05:31:54] <jmkasunich> any project like this involves at least a little engineering, having nothing to do with EMC, just general hookup and such
[05:32:36] <jmkasunich> we don't know your general level of experience, or comfort with jumping in a doing stuff like this
[05:32:55] <djb_rh> understood
[05:33:44] <jmkasunich> if you find online manuals, post URLs when you ask questions, so people can read the manual before they try to reply
[05:33:51] <djb_rh> I've got no machining skills, but a lot of Linux and general computer experience as well as some robotics experience.
[05:34:03] <jmkasunich> sounds encouraging ;-)
[05:34:04] <djb_rh> and a will to learn on the machining side
[05:34:20] <jmkasunich> this isn't a machining project so much as an electrical/electronic one
[05:34:23] <djb_rh> heard of Red Hat?
[05:34:43] <jmkasunich> what is that? ;-)
[05:34:48] <djb_rh> Linux company
[05:34:56] <Jymmm> whats linux?
[05:35:07] <djb_rh> :P
[05:35:08] <jmkasunich> ded rat
[05:35:51] <SWPadnos> Hed Rat?
[05:35:51] <djb_rh> yeah, well, obviously with this crowd I don't say this to brag, but I was the first tech employee hired at RH (one founder was a tech guy, the other wasn't, and I was the third person there)
[05:35:59] <SWPadnos> hmmm - I kind of like that :)
[05:36:07] <SWPadnos> cool
[05:36:11] <djb_rh> I have a computer engineering degree and have been able to solder since I was about 8
[05:36:22] <SWPadnos> child's play ;)
[05:36:25] <cradek> don't they make some clone of Debian?
[05:36:31] <djb_rh> oooh
[05:36:36] <jmkasunich> know any analog stuff?
[05:36:37] <djb_rh> don't make me hurt you, cradek
[05:36:48] <djb_rh> jmkasunich: not as well as digital, but I get by
[05:37:04] <jmkasunich> you should be able to handle this retrofit then
[05:37:07] <Jymmm> cradek: No you silly goose... a clone of CP/M
[05:37:23] <jmkasunich> just ask questions on the users list as issues come up
[05:37:46] <cradek> or here
[05:37:47] <djb_rh> jmkasunich: yeah, I'm still trying to figure out if it is worth my time. I bought a mini-mill and mini-lathe to learn machining on, and plan to convert them to CNC with EMC using the Stirling kits
[05:38:00] <jmkasunich> we have an assortment of experts here - nobody is an expert on everything, but somebody can usually help
[05:38:06] <djb_rh> and it looks like the companies that will retro this thing for me would cost in excess of $8k
[05:38:37] <jmkasunich> assuming all the mechanics are OK (motors, screws, nuts) and the amps can be used, you could probably do it for under $1000
[05:38:41] <djb_rh> which seems excessive *if* the motors and encoders can be used
[05:38:44] <djb_rh> yeah, that's what I figured
[05:38:53] <djb_rh> which puts it in the ballpark of definitely worth it to do it myself
[05:39:03] <jmkasunich> motenc or similar card gives you encoder reading and DACs to drive the amps
[05:39:09] <djb_rh> plus I enjoy learning new shit like this that I'll never need to do again
[05:39:18] <jmkasunich> that will take about half the $1000, the rest will be misc bits and pieces
[05:39:23] <djb_rh> ah
[05:39:24] <djb_rh> thanks
[05:39:36] <jmkasunich> of course, it will take $10K in labor if you had to pay yourself ;-)
[05:39:42] <petev> djb: look at www.ajaxcnc.com, probably about $3K
[05:39:44] <djb_rh> heh
[05:40:16] <djb_rh> hmm
[05:40:23] <djb_rh> damn, I missed that one!
[05:40:29] <djb_rh> I found a couple other sites, but not this one
[05:40:31] <SWPadnos> I wonder if I can get just the X and Y motor mounts from them
[05:40:32] <djb_rh> damn, petev
[05:40:36] <jmkasunich> "how to retrofit a bridgeport Boss"
[05:41:00] <Jymmm> http://www.uptimecorp.com/PartData.aspx?ID=64500
[05:41:39] <Jymmm> MIGHT be able to order one, and get the manual ot go with it
[05:41:43] <djb_rh> doesn't appear they use the NC 400's
[05:41:56] <Jymmm> that IS for the NC400
[05:42:05] <djb_rh> err, sorry, I was talking about the Ajax conversion
[05:42:14] <djb_rh> just clicked your link
[05:42:15] <djb_rh> :)
[05:42:18] <jmkasunich> yeah, the ajax uses new drives
[05:42:24] <petev> djb:no, they have their own drives
[05:42:24] <jmkasunich> one of the reasons it costs more
[05:42:43] <petev> djb: but you can use the motors and encoders
[05:43:00] <djb_rh> yeah
[05:45:01] <jmkasunich> swp: back to popping up dialog boxes from HAL?
[05:45:58] <djb_rh> so, is the "ajaxcnc" software just EMC, or their own stuff?
[05:46:25] <Jymmm> This is JUST SO WRONG (Scroll down to ' Tofurky Roast') http://www.tofurkey.com/products/tofurkyfeasts.htm
[05:46:34] <jmkasunich> their own stuff I think
[05:47:08] <jmkasunich> extruded tofurkey tubes!
[05:47:15] <djb_rh> oh, it appears to be Windows stuff, actually
[05:47:16] <djb_rh> yuck
[05:48:49] <jmkasunich> guess steve went away...
[05:48:59] <SWPadnos> sorry - still here
[05:49:20] <jmkasunich> back to popping up dialogs for toolchange?
[05:49:23] <SWPadnos> sure
[05:49:39] <SWPadnos> (or other as yet unspecified "hardware" functions)
[05:49:39] <jmkasunich> I had been thinking of simpler widgets:
[05:49:49] <jmkasunich> button that pulses a HAL pin
[05:49:57] <jmkasunich> toggle button that toggles a HAL pin
[05:50:05] <jmkasunich> light that turns on/off based on a HAL pin
[05:50:16] <jmkasunich> indicator that changes color and/or text based on a HAL pin
[05:50:30] <jmkasunich> and indicator button that combines indicator and button, uses two pins
[05:51:04] <jmkasunich> along with a "language" that would let you say "I want N of this widget, M of that one, arranged in a window like so..."
[05:51:05] <SWPadnos> simple dialog - bit in, bit out, shows a string, press button to set output true and dismiss dialog
[05:51:27] <jmkasunich> but you need to change the string, based on the dsired tool number
[05:51:31] <SWPadnos> well - that's the GUI designer's job (like QT Designer, KDevelop, Gambas (I thikn))
[05:51:47] <cradek> I noticed today that IO_Show on my BDI4.30 test machine doesn't run
[05:51:57] <SWPadnos> userspace can user sprintf with varargs
[05:51:58] <cradek> does anyone use BDI4.30?
[05:52:13] <jmkasunich> I'm at 4.27
[05:52:21] <jmkasunich> I think Ray made the jump
[05:52:26] <SWPadnos> sort of - I had a partially failed upgrade from 4.20
[05:52:28] <cradek> isn't that one of the ones with the FP bug?
[05:52:35] <SWPadnos> 4.29, I think
[05:52:40] <cradek> no, 29 fixes it
[05:52:41] <SWPadnos> which FP bug?
[05:52:55] <SWPadnos> 4.20 may be
[05:52:56] <cradek> FP-intensive programs (like emc guis) crash when emc is running
[05:53:02] <jmkasunich> I think 4.30 has no known bugs
[05:53:15] <SWPadnos> hmm - hadn't noticed any of that, though I did start getting crashes a few days ago
[05:53:15] <cradek> jmkasunich: well, IO_Show doesn't run
[05:53:28] <cradek> jmkasunich: or, at least, not for me
[05:53:34] <jmkasunich> oops, I wasn't clear
[05:53:52] <jmkasunich> I never use emc1, or the emc1 variant that comes on the BDI
[05:54:10] <jmkasunich> I use the BDI as a way to get a RT capable distro, and the distro is pretty stable
[05:54:14] <cradek> jmkasunich: ah, that could explain it
[05:54:20] <jmkasunich> I don't know anything about the emc that is on it
[05:54:25] <SWPadnos> does it bomb out, or just not work?
[05:54:33] <cradek> jmkasunich: well, I don't believe in the emc that's on it, but that's another story
[05:54:41] <cradek> SWPadnos: I think it gives a tcl error
[05:54:52] <cradek> SWPadnos: window never comes up
[05:54:55] <SWPadnos> emc1 or emc2?
[05:54:59] <cradek> 1.5
[05:55:03] <SWPadnos> (or emc 1.5234234574568)
[05:55:05] <SWPadnos> ok
[05:55:13] <SWPadnos> I can't help then :)
[05:55:18] <jmkasunich> EMCsqrt(2)
[05:55:31] <cradek> emc "Not a bastard child" 1.5
[05:55:32] <SWPadnos> sqrt(2.5)-ish
[05:55:47] <cradek> sorry, I'm trolling now
[05:56:21] <SWPadnos> emc "don't say that about my parents" .6
[05:59:09] <petev> SWP: did you update to the latest CVS a few days ago?
[05:59:11] <SWPadnos> so - on the GUI thing - I think we're looking for the same thing, but the real question is how to do it
[05:59:22] <SWPadnos> I did, but I have a problem with that machine,
[05:59:30] <SWPadnos> so I haven't run emc since then
[05:59:42] <petev> hmm, because I started getting RT issues after updating
[05:59:53] <SWPadnos> ok - could be related
[05:59:55] <petev> locks most of linux up pretty good
[06:00:01] <petev> seg faults on exit sometimes
[06:00:10] <petev> couldn't track it down
[06:00:25] <SWPadnos> I updated several days ago, and started having spontaneous reboots when EMC was running
[06:00:46] <SWPadnos> I wasn't sure that it had to do with the update though, because it happened on the HEAD and lerman branches
[06:01:02] <petev> hmm, maybe related as I think something in the RT code is being corrupted
[06:01:11] <SWPadnos> I was also running remote X, so reboots weren't obvious
[06:01:37] <SWPadnos> (they sseemed to be klockups, until I'd look over at the other PC, and see that it was doing the POST memory count)
[06:01:56] <SWPadnos> lockups, not klockups (no new word there :) )
[06:02:31] <SWPadnos> so I tried to do an apt update (synaptic, actually), since the machine was a pretty old install
[06:03:06] <petev> hmm, I'm running on a 4.20 BDI with a few packages added
[06:03:08] <SWPadnos> now, I'm back to seeing X, but for some reason, xfce runs, even though it isn't trechnically installed (and kdm runs, but pops me straight to xfce)
[06:03:16] <petev> all was stable until recently
[06:03:21] <SWPadnos> that's what I have, except for all the packages removed ;)
[06:03:51] <SWPadnos> maybe it was a timebomb of some sort - I hadn't done anything "interesting" to cause the crashes
[06:04:05] <SWPadnos> and the system had been stable for months before that
[06:04:36] <petev> yeah, same here
[06:04:44] <petev> it's still stable if I don't run EMC
[06:04:53] <SWPadnos> yes - so was mine
[06:09:39] <Yuga> can any one tell me y one would wrap a wire around a ferrite ring? what is the reason? have seen it many times
[06:10:13] <jmkasunich> to pass thru the center of the ring more than once (which increases the noise filtering effect of the ring)
[06:11:55] <jmkasunich> petev, SWPadnos: you are aware that 4.29 and 4.30 use a different kernel and RT than earlier ones?
[06:12:09] <petev> yes
[06:12:11] <SWPadnos> I upgraded the kernel - that did work
[06:12:19] <petev> why I didn't want to upgrade
[06:13:15] <petev> jmkasunich : so what have we decided regarding widgets if anything?
[06:13:26] <petev> are we making NML widgets and HAL widgets?
[06:13:39] <SWPadnos> (hopefully that they're a necessary / desirable addition)
[06:13:43] <Yuga> jmkasunich... so all it realy does is filter out noice?
[06:13:56] <jmkasunich> I will be making HAL widgets (if nobody beats me to it)
[06:14:01] <SWPadnos> Yuga, yes - ferrite cores are noise filters
[06:14:08] <jmkasunich> NML widgets are up to someone else
[06:14:28] <petev> I don't care who does it
[06:14:39] <petev> I just want to see a common goal for developers
[06:14:46] <Yuga> ok.. so i can just go get any old ferrite ring and wrap my speaker cable around it... it shouldnt matter what ferrite core i use?
[06:14:51] <SWPadnos> as long as there's a documented way to make a userspace app that can have HAL pins, then there can be remote GUIs and the like, as people see fit
[06:14:55] <jmkasunich> I suppose it would be nice if one executable could place both kinds of widgets in one window
[06:15:02] <petev> I'm ready to start some type of widget stuff so a goal would be nice
[06:15:22] <jmkasunich> but I will always want another executable that does HAL widgets only
[06:15:26] <petev> that's what I would like to see
[06:15:42] <petev> are you going to make QT widgets?
[06:15:58] <jmkasunich> GTK - it's the only toolkit I've ever used
[06:16:11] <jmkasunich> it's also used for halmeter and halscope, so it's a natural for other hal accessories
[06:16:16] <petev> hmm, QT designer seems much better than Glade
[06:16:17] <SWPadnos> do you have the QT NML widgets that Paul (and anon, I think) started?
[06:16:31] <petev> yes, I saw what paul did
[06:16:48] <petev> not much there, mostly a QT widget base class for NML status/command
[06:16:54] <petev> he defined 2 classes
[06:17:06] <SWPadnos> I had tried to make a QT Designer "axis" qidget, but making them installable into Designer was hard
[06:17:15] <petev> it looks like a good start to build on if we go QT
[06:17:22] <SWPadnos> do you have the code?
[06:17:27] <petev> yes
[06:17:28] <SWPadnos> ok
[06:17:42] <cradek> I though QT had an unacceptable license
[06:17:49] <jmkasunich> QT designer and Glade and simular tools output source code don't they?
[06:17:58] <petev> I'm still reading the tutorial on how to make them designer enabled
[06:18:00] <jmkasunich> similar
[06:18:01] <SWPadnos> did I send that to you (I knew I had sent it to someone, can't remember who)
[06:18:13] <petev> no, QT is free for non-comercial use
[06:18:22] <SWPadnos> they allow you to easily build UIs, with pre-made widgets
[06:18:23] <petev> can't remember who sent it
[06:18:54] <SWPadnos> ok - I think I sent it to you or lerman - doesn't matter
[06:19:03] <petev> so is it QT or GTK?
[06:19:08] <petev> GTK is C only
[06:19:15] <petev> wo that causes a problem with NML
[06:19:20] <petev> wo/so
[06:19:26] <jmkasunich> SWP: yes, but don't they do it by having you build the GUI on the screen, then spit out the code to be embedded in your application?
[06:19:35] <SWPadnos> almost
[06:19:57] <SWPadnos> there's also a .ui file that is used to build the window (not sure if it's used at runtime)
[06:20:11] <jmkasunich> I see
[06:20:14] <jmkasunich> need to read more
[06:20:27] <petev> likewise
[06:20:29] <SWPadnos> that was part of my problem - I didn't immediately see how to use the damned UI in an actual program
[06:20:39] <jmkasunich> I want a single executable that reads a file at runtime to decide what widgets to use and where to place them
[06:20:55] <petev> that wouldn't be too hard
[06:20:57] <SWPadnos> yes - the designer apps should be able to do that
[06:21:02] <jmkasunich> not one executable for every layout
[06:21:10] <petev> what about the C++ issue with NML?
[06:21:18] <SWPadnos> especially if they read a "resource" file to create their child widgets
[06:21:23] <petev> are you going to put a wrapper on NML?
[06:21:26] <SWPadnos> don't know about that
[06:21:32] <jmkasunich> can't C++ code call C functions like GTK?
[06:21:42] <SWPadnos> yes, but C can't necessarily call C++
[06:21:47] <petev> exactly
[06:21:52] <jmkasunich> so write it in C++
[06:21:53] <SWPadnos> and RCSLIB is C++
[06:22:02] <petev> yes, but GTK doesn't support C++
[06:22:10] <SWPadnos> QT uses C++, so that's not an issue
[06:22:15] <petev> correct
[06:22:22] <jmkasunich> gtk is just a library, C++ can call it
[06:22:27] <petev> I think there are other reasons QT is better as well
[06:22:35] <jmkasunich> to each their own
[06:22:43] <petev> yes, but GTK code has to call NML code too
[06:22:47] <SWPadnos> the license thing can be an issue though
[06:22:58] <petev> what license thing?
[06:23:02] <SWPadnos> "non-commercial use" eliminates e.g. Sherline
[06:23:05] <SWPadnos> QT
[06:23:08] <petev> oh
[06:23:23] <SWPadnos> hence the adamant GPL squad :)
[06:23:24] <petev> all sherline would have to do is buy a copy of QT
[06:23:31] <petev> shouldn't be a big deal for them
[06:23:32] <SWPadnos> and a license to distribute
[06:23:34] <petev> $3k I think
[06:23:46] <jmkasunich> * jmkasunich is gonna write a HAL only "virtual control panel" app, using C, GTK, and no NML, which will live in src/hal/utils and have _no_ EMC specific code in it
[06:23:59] <djb_rh> the point is locking out *everyone*, including smaller shops that couldn't necessarily afford Qt
[06:24:00] <jmkasunich> what others do for EMC is up to them
[06:24:01] <SWPadnos> and the same for any other commercial interest that wants to bundle EMC (like Jon Elson)
[06:24:47] <djb_rh> avoiding software that has "non-commerical only" clauses in software you want to be 'free' is a good thing
[06:24:48] <SWPadnos> ok - as long as there's an interface (documnented, of course) to HAL pins from userspace apps, I think that's all we need
[06:24:53] <petev> hmm, so jmk has his plan, but there doesn't seem to be any agreed upon goal
[06:25:11] <SWPadnos> userspace "pins" is the immediate goal for jmk, I gather
[06:25:28] <jmkasunich> SWP: userspace pins have been in HAL since the beginning
[06:25:37] <SWPadnos> after that, there's a library that UI designers can use to make widgets talk to HAL from their favorite GUI builder
[06:25:41] <jmkasunich> pins controlled by widgets are the new thing I'm talking about
[06:25:51] <SWPadnos> ok - even easier ;)
[06:26:27] <petev> SWP: the library seems like it will need to be widget (QT, GTK, etc.) specific
[06:26:33] <petev> or do you see another way to do it?
[06:26:41] <jmkasunich> hal.h documents the API for pins, userspace and/or realtime
[06:26:53] <SWPadnos> nope - the UI is definitely widget set-centric
[06:27:03] <petev> so which widget set?
[06:27:14] <jmkasunich> doesn't have to be limited to one
[06:27:19] <SWPadnos> GTK from jmk, QT from ???, xlib from ??
[06:27:21] <SWPadnos> etc.
[06:27:25] <jmkasunich> obviously some duplication of effort though...
[06:27:33] <SWPadnos> svgalib, for that matter, or curses
[06:27:47] <petev> well that will be ugly unless all sets are complete
[06:27:53] <petev> how do a make a GUI using some QT and some GTK?
[06:28:05] <jmkasunich> you don't
[06:28:10] <petev> exactly
[06:28:14] <SWPadnos> *very* carefully, and with great pain
[06:28:38] <SWPadnos> but the set of widgets is pretty small - it's the combinations that get complicated
[06:29:00] <petev> well, I have ideas for widgets that may go beyond what others think
[06:29:21] <jmkasunich> a full blown GUI needs a larger set of widgets than my HAL only version
[06:29:23] <petev> things like MDI, plot, back plot, tool setup, etc.
[06:29:31] <SWPadnos> that's not HAL
[06:29:40] <petev> an MDI widget might have a gcode editor and maybe conversational stuff from CP1
[06:29:50] <jmkasunich> things like a file selector dialog, and all the ones that pete just listed
[06:29:58] <petev> no, but it's still QT or GTK or whatever
[06:30:06] <SWPadnos> yes
[06:30:27] <petev> seems like a lot of widgets to me
[06:30:39] <petev> and some will be a fair amount of work
[06:30:41] <SWPadnos> sure, but not HAL widgets
[06:30:51] <petev> agreed
[06:30:59] <SWPadnos> the file selector and editor will already be done in any reasonably advanced widget set
[06:31:04] <petev> but a lot of work to duplicate for QT, GTK, Tcl, etc.
[06:31:09] <SWPadnos> same with a single line editor
[06:31:12] <petev> true
[06:31:25] <SWPadnos> buttons, text strings, etc are all done
[06:31:41] <jmkasunich> existing GUIs = fixed set of widgets, fixed screen layout, some internal logic, send/receives NML
[06:31:47] <SWPadnos> it's a matter of connecting them to things that are useful in the context of EMC
[06:32:25] <jmkasunich> my HAL virtual control panel = variable (but limited) widget set, variable layout at runtime, HAL connections only
[06:33:07] <petev> why build all that framework and limit to HAL only?
[06:33:20] <SWPadnos> because that's the part he's writing ;)
[06:33:21] <jmkasunich> are you (pete) talking about something = variable (large) widget set, variable layout, some logic, and NML messages?
[06:33:40] <petev> yes, if we are keeping NML :)
[06:35:02] <SWPadnos> count on that for a while :)
[06:35:14] <jmkasunich> why build "all that" and limit to HAL only? because the small widget set and lack of internal logic that I have in mind means its not really "all that", actually pretty simple
[06:35:35] <petev> well, I mean the framework
[06:35:44] <petev> you will have config code, and layout code
[06:35:49] <SWPadnos> yeah - it's tow different domains, that only overlap because they both have GUI parts
[06:35:53] <SWPadnos> two, not tow
[06:36:10] <petev> seems like a bit of work
[06:36:38] <petev> only two domains if you beleive SW buttons are different than HW buttons
[06:36:55] <petev> otherwise there is overlap
[06:37:18] <jmkasunich> true there is overlap, but what I have in mind is a small subset of what you have in mind
[06:37:42] <jmkasunich> small enough that it becomes qualitatively differnet
[06:37:44] <SWPadnos> no - I believe that editing a file is different from setting a HAL pin
[06:37:51] <petev> yes, but the framework and all the buttons could be levereaged
[06:37:57] <SWPadnos> yes - they can
[06:38:04] <SWPadnos> and no reason why they wouldn't be
[06:38:28] <jmkasunich> well pete is talking about using Glade or the QT equivalent
[06:38:40] <petev> how would I leverage jmks work if we don't uset he same widget set?
[06:38:48] <SWPadnos> yes, or gambas (though it is BASIC-like)
[06:38:48] <jmkasunich> I was gonna use a simple text file to tell the app what widgets to use and where to put them
[06:39:04] <SWPadnos> widget creation will be different, but the logic isn't
[06:39:15] <petev> jmk: so layout would be trail and error?
[06:39:18] <jmkasunich> I would not give the configurator full access to all the options of the toolkit, only a small and simple subset
[06:39:40] <SWPadnos> error trail :)
[06:39:58] <petev> trail/trial
[06:40:03] <SWPadnos> use something like HTML or the X screen layout stuff:
[06:40:07] <jmkasunich> to an extent - the same extent that coding is trial and error... if you know what you want, you don't have to randomly trial and error it
[06:40:36] <petev> yeah, but GUI layout is faster visual, I don't care if you know what you want
[06:40:37] <SWPadnos> button2 RightOf button1 label "Cycle Start" HALPIN BIT
[06:40:43] <petev> try it and you will see
[06:40:47] <jmkasunich> (remember, I've never used Glade or the like, I did the layout for halscope using "trial and error"
[06:41:06] <SWPadnos> absolutely - I use BC++ Builder on Windows, and couldn't want to live without it for GUI apps
[06:41:26] <jmkasunich> and that needed a make/run cycle... what I'm thinking about will be more like an interpreter
[06:41:43] <SWPadnos> the config file language doesn't prevent omeone from making / adapting a GUI designer to create those files
[06:41:53] <SWPadnos> s/omeone/someone/
[06:42:04] <petev> swp: who is going to do that?
[06:42:08] <SWPadnos> unknown
[06:42:11] <SWPadnos> but it's possible
[06:42:14] <petev> why not use a file from an existing designer?
[06:42:17] <jmkasunich> a well designed config file language wouldn't, I need to make sure I don't screw it up
[06:42:20] <SWPadnos> OK -glade
[06:42:22] <jmkasunich> that is one possibility
[06:42:28] <jmkasunich> (using an existing file format)
[06:42:45] <SWPadnos> makes sense to me
[06:43:10] <SWPadnos> unless there's a lot of other crap in there which is irrelevant, and also required
[06:43:19] <jmkasunich> but glade will probably let the user pick any GTK widget, I only want them to use the subset of widgets that map to HAL pins
[06:43:41] <SWPadnos> I wouldn't make that restriction - why not allow file pickers and the like?
[06:44:00] <jmkasunich> so you pick a file... now what are you gonna do with it?
[06:44:02] <SWPadnos> (though they'd have to write some code to get the file to *mean* anything to emc
[06:44:08] <jmkasunich> (remember, no coding allowed)
[06:44:21] <SWPadnos> that's where petev's file picker comes in :)
[06:44:24] <petev> why no coding allowed?
[06:44:37] <petev> it would be nice, but why place a restriction
[06:44:47] <SWPadnos> the idea is that an integrator can configure a GUI without writing code
[06:44:47] <jmkasunich> that is my rule for HAL
[06:45:00] <petev> agreed
[06:45:02] <jmkasunich> HAL is a toolbox that lets people build realtime control stuff without writing C
[06:45:07] <petev> but until we get there, why make it hard?
[06:45:10] <SWPadnos> or c++
[06:45:27] <jmkasunich> C, C++, tcl, any programming langauge
[06:45:38] <jmkasunich> actually HAL is a language
[06:45:50] <jmkasunich> a langauge that describes control systems
[06:46:53] <jmkasunich> those systems consist of interconnected blocks... it should be easy for a programmer to write a new block, but a non-programmer should be able to connect existing blocks to build things
[06:47:38] <SWPadnos> OK - so they'll be able to make a "panel" with your widgets, but not a full-blown, file-loading GUI
[06:47:51] <jmkasunich> right - hence the name "virtual control panel"
[06:48:08] <SWPadnos> duh - OK :)
[06:48:28] <jmkasunich> the EMC connection would be a full blown GUI that could use HAL pins instead of internal widgets for some inputs
[06:48:44] <jmkasunich> and I would use those pins only for stuff I wanted to get from physical inputs
[06:48:54] <SWPadnos> or widgets that have connections that can be made from within one of the GUI designers
[06:49:21] <jmkasunich> yeah (I think, not sure I understood your statement)
[06:50:12] <SWPadnos> some GUI conponents have parameters (sometimes called properties) that can be connected to other components
[06:50:35] <SWPadnos> actually, GnuStep has the exact model you'd want for its GUI design apps
[06:50:51] <SWPadnos> (at least, NextStep did, and GnuStep should have most of it by now)
[06:51:07] <jmkasunich> question: how would you address MPG... one approach, you let the designer place every button (axis select, scale factor x1,x10,x100, etc) and somehow connect them to logic that does the work
[06:51:46] <jmkasunich> another approach: you have an MPG widget, that already contains all the buttons and the logic, in a pre-defined layout, and you place that in the larger GUI window with the designer
[06:51:51] <petev> yes, I would make all the controls independant
[06:52:20] <petev> why do you need to tie axis select to resolution?
[06:52:23] <SWPadnos> that would be my approach - you don't know how many axes there are, and it seems silly to have a parameter that tells the widget how many axes to select from, what their names are, etc.
[06:52:25] <jmkasunich> so you have visible widgets for the buttons, and then an invisible widget with the logic needed for MPG control?
[06:52:44] <SWPadnos> that's one possibility
[06:52:54] <jmkasunich> axis select in the MPG context: you have one handwheel, which axis do you want it to move?
[06:52:56] <petev> wouldn't the logic be just sending NML messages?
[06:53:01] <SWPadnos> you can also have a visible "MPG on" button, that has the MPG code "behind" it
[06:53:27] <petev> this is like what SWP means about a parameter that comes from another widget
[06:53:33] <jmkasunich> (note, you might also have three handwheels, then you could dedicate one per axis and drop the axis select)
[06:53:47] <SWPadnos> another good reason for the controls to be separate
[06:54:00] <petev> agreed
[06:54:20] <petev> I have found that the smallest block that makes sense is usually the best
[06:54:33] <jmkasunich> I'm having trouble treating the logic part as a widget
[06:54:40] <petev> and the blocks should match the real world objects they model
[06:55:00] <SWPadnos> what logic is there in a handwheel control?
[06:55:10] <petev> the logic could be put into a widget with no display for a HW MPG and one with for SW based
[06:55:20] <petev> the logic that sends the NML message
[06:55:23] <SWPadnos> it gets a count, multiplies by something, and sends the result somewhere
[06:55:36] <jmkasunich> logic: if ( new_hw_pos != old_hw_pos) {
[06:55:45] <petev> yes, and reads axis selected from some other widget
[06:55:47] <jmkasunich> delta = new_hw_pos - old_hw_pos
[06:56:01] <jmkasunich> joglen = delta * scale (scale comes from scale buttons)
[06:56:06] <SWPadnos> no - the selection should be done elsewhere - with a demux block
[06:56:22] <jmkasunich> send nml jog message to the proper axis, with joglen as the distance to move
[06:56:23] <SWPadnos> think in simplest terms
[06:56:39] <SWPadnos> I thought this was a HAL jog wheel widget??
[06:56:40] <petev> SWP: how do you see it?
[06:57:10] <SWPadnos> (which wouldn't exist, BTW, unless you use a mouse to move the wheel)
[06:57:29] <SWPadnos> look at what a handwheel does - it outputs pulses
[06:57:34] <jmkasunich> need to distingish between the wheel itself, and the "jogwheel" logic, which takes the position from a wheel (real or virtual) and turns it into jog commands
[06:57:45] <petev> agreed
[06:57:50] <SWPadnos> sure, but that's not GUI, it's UI
[06:57:53] <jmkasunich> the wheel itself is either a screen widget, or an encoder counter
[06:57:56] <SWPadnos> hence no graphical designer
[06:58:14] <jmkasunich> but isn't the logic part of the (G)UI executable?
[06:58:16] <petev> ok, so you see all the logic behind the GUI being in the UI
[06:58:20] <jmkasunich> if not there, then where?
[06:58:45] <petev> I think SWP is saying it's not
[06:58:49] <SWPadnos> the screen widget would be something that outputs a number (like the HAL encoder input component), based on some mouse movement, and with a graphical representation
[06:59:09] <SWPadnos> but if you want to use a hardware encoder, you don't use a screen widget to represent it
[06:59:19] <jmkasunich> that is the easy part (and the generic part, I have no problem with that widget being part of the virtual panel app)
[06:59:45] <jmkasunich> the hard part (not really, but the non-generic part) is the axis/scale/NML logic
[07:00:04] <SWPadnos> that's independent of whether you have a GUI or a hardware wheel
[07:00:10] <petev> in normal GUI app you develop the GUI part with RAD tool, then write some code to glue it all together
[07:00:19] <SWPadnos> and so it should be a separate block, which is wired in with HAL files, not GUI files
[07:00:20] <petev> where does this glue code go?
[07:00:30] <jmkasunich> ok, part of our problem is that to date, EMC has used GUI to refer to both the screen stuff, and the underlying logic
[07:00:41] <petev> agreed
[07:00:45] <SWPadnos> heh - problem #1
[07:01:10] <jmkasunich> I was assuming that we were going to retain the same model here, with the logic embedded in the same module that draws the widgets
[07:01:28] <jmkasunich> and my HAL VCP thing was a rebellion against that - it has no logic at all
[07:01:44] <jmkasunich> intended to be used with "something else" that has logic and NML
[07:01:55] <petev> If we want to stick to the NIST model strictly, the logic probably doesn't belong in the GUI
[07:01:59] <SWPadnos> that's exactly what I'm saying - screen widgets for the VCP are *exactly* like buttons or encoder wheels
[07:02:00] <jmkasunich> or used alone, to talk to CL, or test hardware, or whatever
[07:02:09] <SWPadnos> or LEDs or whatever
[07:02:18] <SWPadnos> if the input goes true, the light turns on
[07:02:26] <SWPadnos> if the button is pressed, the output goes true
[07:02:27] <jmkasunich> right
[07:02:28] <SWPadnos> etc.
[07:02:29] <SWPadnos> no logic
[07:02:48] <jmkasunich> but a file open dialog - how do you do "no logic" with that?
[07:02:49] <SWPadnos> so the handwheel is just something that exports a signed pisotion or offset
[07:02:56] <SWPadnos> that's not HAL
[07:03:16] <SWPadnos> there has to be some logic, but it also depends on what you have for the EMC interpreter
[07:03:19] <jmkasunich> handwheel position would most likely be a signed 32 bit int
[07:03:29] <SWPadnos> if you have string "pins" in your GUI, then it's not a big problem
[07:03:56] <jmkasunich> string pins don't exist in HAL. I don't know how they would fit, not well IMO
[07:03:57] <petev> we are in the weeds, let's look at the big picture and see how the pieces fit an where code should go
[07:04:10] <SWPadnos> you connect the string "output" of the file load dialog to the string "input" of the editor
[07:04:31] <SWPadnos> (signals and slots work somewhat like this in QT)
[07:04:33] <petev> ok, so whre does this editor, glue logic, and other stuff live?
[07:04:41] <petev> is it code linked with the GUI?
[07:04:42] <jmkasunich> but its not just a name, you also have to tell the dialog when to pop up
[07:04:57] <jmkasunich> today it is part of the GUI
[07:05:09] <SWPadnos> yes - there are ways to do that similarly (set the "visible" property to true, from the output of a button)
[07:05:10] <jmkasunich> tomorrow, I haven't the slightest idea
[07:05:20] <petev> I know where it is today, just trying to figure out if that's what SWP wants
[07:05:59] <SWPadnos> note that some logic is fine, just not for the HAL parts - those can connect to login within HAL (like ladder)
[07:06:42] <SWPadnos> the overall GUI will need to have pieces that know to do certain things when emc's status changes
[07:06:47] <petev> so you want the HAL widgets to talk directly to the HAL and not send NML?
[07:07:05] <jmkasunich> yes
[07:07:18] <SWPadnos> It's not specifically that I want these things - I'm trying to forward the discussion that I jumped in on
[07:07:26] <jmkasunich> if you want something to send NML, route the HAL to some "logic code" that decides what message to send
[07:07:28] <petev> that's where I started and everyone shot it down and said they should send NML to task
[07:07:49] <SWPadnos> but yes, I would like to have some "UI blocks" that can be connected easily, similar to the way HAL is configured for drivers
[07:08:02] <petev> that's what I want as well
[07:08:27] <jmkasunich> I think there has been a lot of mis-communication of ideas (I for one do better when I can draw pictures) and also a little of people changing their minds and coming around to positions they originally opposed
[07:08:34] <SWPadnos> just make one giant HAL<->NML blob, with a pin for each possible NML message, on both directions :)
[07:09:14] <jmkasunich> that is one approach (one I originally favorded) but you can't do it in detail - some NML messages simply don't map to pins
[07:09:24] <jmkasunich> (like "open g-code file")
[07:10:09] <SWPadnos> the "blob" can do the right thing
[07:10:13] <jmkasunich> of course, if it doesn't map to a HAL pin then you'll never want to do it with a physical button anyway
[07:10:15] <SWPadnos> that would allow a panel button to cause a file dialog to pop up ;)
[07:10:36] <petev> yes, but I don't think we need that, do we?
[07:10:49] <SWPadnos> heh - hopefuilly not
[07:10:54] <petev> good
[07:10:54] <jmkasunich> the message isn't "ask the user for a filename", the message is "the user specified this file, now task needs to open it"
[07:11:00] <jmkasunich> so the message needs to contain a name
[07:11:11] <jmkasunich> names don't travel on HAL pins ;-)
[07:11:16] <petev> well we certainly don't need that
[07:11:27] <jmkasunich> right
[07:11:30] <petev> what would HAL do with it?
[07:11:34] <jmkasunich> nothing
[07:11:37] <SWPadnos> heh
[07:11:50] <jmkasunich> that needs to come from a real GUI with a G
[07:11:59] <jmkasunich> not a VCP
[07:12:30] <petev> ok, so where does GUI logic live? Is it still linked with the GUI?
[07:12:35] <jmkasunich> also things like displaying the current line of g-code - simply not a VCP job
[07:12:50] <petev> do we try to make GUI independant libs that all GUIs can share?
[07:12:57] <SWPadnos> well - there's a core part of this that's still "emc"
[07:13:10] <SWPadnos> that's where a lot of the logic could sit
[07:13:23] <jmkasunich> I was (still am, I think) envisioning a GUI like today, with logic inside, but with some (not all) of its inputs thru HAL pins, so that some things could come from a VCP or a real button
[07:13:37] <SWPadnos> that would need to have hooks to both the HAL side, the NML side, and the GUI side
[07:13:48] <SWPadnos> also, pluggable interpreters would connect, etc.
[07:13:57] <jmkasunich> not interpreters
[07:14:06] <SWPadnos> whynot?
[07:14:07] <jmkasunich> interpreters connect to task
[07:14:17] <jmkasunich> today they are linked with task
[07:14:22] <petev> yes
[07:14:36] <jmkasunich> later they might be runtime linkable or something, but always associated with task, not GUI
[07:14:37] <SWPadnos> OK - so the interpreter connects to task - so does a lot of other stuff
[07:14:59] <jmkasunich> GUI talks NML to task, as do motion and iocontrol
[07:15:07] <jmkasunich> interpreter is actually part of task
[07:15:12] <SWPadnos> that's not possible, because the GUI may need to be inviklved with some interpreters (like STL, for example)
[07:15:19] <petev> well, that's interesting, what if different GUIs supported different interpreters, but all talked the same cannonical stuff to task
[07:15:28] <SWPadnos> it is now, but doesn't have to be (or does it?)
[07:15:29] <jmkasunich> then you are proposing even farther ranging changes
[07:15:35] <jmkasunich> that hurts my head ;-/
[07:15:36] <SWPadnos> over time, yes.
[07:15:47] <SWPadnos> that's the end goal though, IMO
[07:15:58] <jmkasunich> now you know why I stick to the low level stuff
[07:16:03] <SWPadnos> in fact, I'd love to have a GUI that let me choose an interpreter on the fly
[07:16:06] <SWPadnos> heh
[07:16:23] <petev> jmk: just draw pictures :)
[07:17:32] <SWPadnos> I thikn it might be past my bedtime
[07:17:43] <jmkasunich> getting there for me
[07:17:56] <jmkasunich> I hope somebody was logging
[07:17:57] <petev> ok, I guess we will have to think on this some more
[07:17:59] <SWPadnos> I should be around for a while on Sunday
[07:18:10] <SWPadnos> I am, and logger_aj is on the case as well
[07:18:59] <SWPadnos> Night, guys - it's been fun
[07:19:06] <petev> gnight
[07:19:06] <jmkasunich> goodnight
[07:19:08] <SWPadnos> SWPadnos is now known as SWP_Away
[07:20:37] <jmkasunich> petev: not to beat this fgga GPL thing any worse, but is Peter Wallace in a position to grant GPL (IOW, is he a high mucky-muck at MESA, or a lowly techincal peon)?
[07:21:02] <jmkasunich> s/fgga/fpga/
[07:21:28] <petev> he owns Mesa and wrote the code
[07:21:33] <petev> so I don't see why not
[07:21:43] <jmkasunich> high mucky muck then ;-)
[07:21:46] <petev> yes
[07:22:21] <jmkasunich> good enough
[07:22:53] <jmkasunich> I can't believe the energy folks were spending on that issue...
[07:22:59] <petev> yes
[07:23:40] <petev> I was hoping to get some clear goal out of today, but it wasn't to be
[07:23:57] <jmkasunich> it is very hard
[07:24:02] <petev> I think alex is of the opinion that we should just be fixing bugs
[07:24:17] <petev> I find it hard to do that without a clear plan of the architecture
[07:24:25] <petev> maybe I should just stick to HAL
[07:24:42] <jmkasunich> thats how I feel
[07:24:50] <jmkasunich> although I also work on the motion controller
[07:25:35] <jmkasunich> alex wants to avoid things that lead to massive brokeness before they lead to massive improvements
[07:25:59] <petev> understood, but I think some bugs get introduced because there is no clear architecture
[07:26:13] <petev> people try to fix or enhance one thing and break another
[07:26:18] <jmkasunich> I would like our new (G)UIs and VCPs and whatever else to be able to work alongside mini, tkemc, and Axis, not force them out or force them into a massive rewrite
[07:26:39] <petev> I think that's totally possible
[07:26:45] <jmkasunich> I agree, it would be better if there was a good arch description and plan
[07:26:50] <petev> they just wouldn't be able to use the new stuff
[07:27:02] <petev> axis is a bit of a problem now though
[07:27:08] <jmkasunich> NML is the common interface for that (or can be - it's the least painfull path)
[07:27:08] <petev> it keeps state info
[07:27:19] <jmkasunich> well thats just wrong, and needs fixed ;-)
[07:27:35] <petev> I think it's only because there is no good plan or docs
[07:27:38] <jmkasunich> it doesn't play well with the existing GUIs either
[07:27:45] <petev> how would the axis guys know any better?
[07:28:04] <jmkasunich> right - so much of the design info is passed along by word of mouth
[07:28:11] <petev> exactly
[07:28:35] <jmkasunich> did you see the docs pages I did a couple years ago (I sent the URL in one of the emails today)
[07:28:54] <petev> hmm, I have several links to your's and alex's stuff
[07:29:02] <petev> not sure if it's what you sent
[07:29:12] <jmkasunich> just a sec
[07:29:28] <petev> was it this?
[07:29:29] <petev> http://home.att.net/~jmkasunich/EMC_Docs/EMC_Home.htm
[07:29:34] <jmkasunich> yeah
[07:29:43] <petev> yes, I have seen that
[07:29:55] <jmkasunich> that is the best I was able to come up with, still full of holes
[07:30:04] <petev> yes, it helped me
[07:30:06] <jmkasunich> I asked for corrections and input, got a whole lot of nuttin
[07:30:13] <petev> it was the best doc I saw
[07:30:19] <petev> yep
[07:30:34] <jmkasunich> we really need detailed docs for every NML message:
[07:30:35] <petev> that's pretty much what I got when I asked others how they would do it
[07:30:41] <petev> alex was the only one to even try
[07:31:13] <jmkasunich> name, data fields that are passed, who sends it, who receives it, what they do when they get it, etc, etc
[07:31:39] <petev> that would be great
[07:31:49] <petev> are there any tools for NML like there are for RPC?
[07:32:01] <petev> tools like that would force all this to be documented
[07:32:14] <jmkasunich> not that I'm aware of
[07:32:22] <petev> and would help in generating code that matched
[07:32:43] <petev> ray mentioned some java compiler which I think I had a run in with EMC1
[07:32:52] <jmkasunich> the original (EMC1) emc.hh and emc.cc files were generated by a java tool
[07:33:00] <petev> it was a pain and paul told me I just didn't want to go there when I asked
[07:33:09] <jmkasunich> but that certainly didn't force any documentation
[07:33:15] <jmkasunich> we dropped it for emc2
[07:33:23] <petev> that was probably good
[07:33:31] <petev> rpcgen uses a .x file
[07:33:48] <petev> it generates stubs for both client and server and header files from it
[07:33:51] <jmkasunich> yeah, I saw that when I skimmed the pages you pointed me at
[07:34:13] <jmkasunich> one of the pages was a pretty decent tutorial
[07:34:20] <petev> I'm sure there are better tools as this is the old Sun RPC
[07:34:41] <petev> yeah, the one was a tutorial on RPC , the other on rpcgen
[07:34:42] <jmkasunich> I still have a problem with the difference between a procedure call and a message
[07:35:00] <jmkasunich> message: you send it and carry on with life
[07:35:09] <petev> to me a message is a generic thing that communicates something
[07:35:09] <jmkasunich> call: you make the call and wait for a result
[07:35:19] <petev> a procedure call vs a packet, is just how the message is implemented
[07:35:25] <petev> yep
[07:35:36] <jmkasunich> A message sends data somewhere, without messing with the thread of execution
[07:35:40] <petev> but the same can happen with the call
[07:35:53] <petev> you are talking about synchronous vs asychnronous
[07:36:02] <petev> imagine a procedural interface
[07:36:10] <petev> you make one call to send a command
[07:36:15] <petev> the do what you like
[07:36:16] <jmkasunich> rpc is actually implemented as "send a message, wait for a response"
[07:36:22] <petev> make another call to check status
[07:36:28] <petev> same thing
[07:36:37] <petev> that's asynch
[07:36:57] <petev> you make a call and it completes command and returns status
[07:37:02] <petev> that synchrounous
[07:37:20] <petev> both can be implemented with procedures, packets, or whatever
[07:37:29] <petev> at least that's how I see it
[07:37:52] <jmkasunich> ok, the calling thread stops and waits for the response... meanwhile, a thread of execution must run on the callee to execute the called function
[07:37:55] <petev> you are correct about RPC
[07:38:07] <petev> procedural at the top level, but packet based under the hood
[07:38:11] <jmkasunich> where does that thread come from? is a thread spawned when the message shows up?
[07:38:23] <petev> and it supports both sync and asycn as well as timeouts with sync
[07:38:39] <petev> thread on which side, client or server?
[07:38:44] <jmkasunich> or is there only one thread in the callee, and it polls for requests, then executes them and sends replies
[07:39:01] <jmkasunich> server I think... the one that has the function that is being called
[07:39:10] <petev> there is one thread on the client, you make a async or sync call
[07:39:13] <jmkasunich> client is the caller, right?
[07:39:32] <petev> there is code in a librpc or something that implements the server
[07:39:39] <CIA-5> 03paul_c * 10emc2-auto/wiki/ (13 files in 10 dirs): "Auto update wiki from a cron job. Sat Nov 19 05:30:01 GMT 2005 "
[07:39:56] <petev> the server stubs from rpcgen call it for you
[07:40:07] <petev> there are many lower level calls in the rpc lib that allow more control
[07:40:18] <petev> stuff like authentication, etc.
[07:40:45] <jmkasunich> I guess the question I'm asking is an implementation detail, I just have a heck of a time ignoring the low level stuff and thinking high level
[07:41:00] <petev> when used at the simplest level, it just makes your procedure call happen remotely with not much disruption to your code
[07:41:14] <petev> yeah, just think black box
[07:41:21] <petev> well defined interface
[07:41:26] <jmkasunich> * jmkasunich always wants to understand the box
[07:41:32] <jmkasunich> its the hardware engineer in me
[07:41:34] <petev> same priciples for object oriented design
[07:41:38] <petev> hw too
[07:41:43] <petev> well defined bus
[07:41:46] <jmkasunich> OO is another thing I have trouble with
[07:41:51] <petev> you don't care what plugs in
[07:41:55] <jmkasunich> hah!
[07:42:06] <petev> at least in theory :)
[07:42:17] <jmkasunich> except when the impedance doesn't match, or there is noise, or blah, blah blah
[07:42:20] <petev> you get the idea
[07:42:43] <jmkasunich> which is why I always need to be prepared to drop down a level of abstraction or two
[07:43:01] <petev> yeah, but when it works you don't have too :)
[07:43:10] <jmkasunich> when it works...
[07:43:21] <jmkasunich> I think that is at the heart of my issues with high level design
[07:43:44] <jmkasunich> I'm never really comfortable with something unless I can drop down thru the levels of abstraction and understand it all the way down
[07:44:00] <jmkasunich> since my mind can only handle so much, I get nervous when I work at too high a level
[07:44:10] <petev> that is getting harder and harder to do with the complexity of todays systems
[07:44:22] <jmkasunich> I know - I often feel like a dinosaur
[07:44:40] <petev> do you punch down inside the device electronics and understand them on the pyhsical level?
[07:44:54] <jmkasunich> however, I also often get called in to solve problems that others can't fix, because they get stuck at one level of abstraction and can't move around ;-)
[07:45:37] <jmkasunich> getting into semiconductor physics is extremely rare, but sometimes I have conversations that border on it
[07:45:47] <petev> nothing wrong with being able to understand different levels of abstraction, but sometimes you just can't understand all of them
[07:45:55] <jmkasunich> I deal with power electronics, and things like diode recovery touch on that stuff
[07:46:11] <petev> so you are ok at the device level for the most part
[07:46:31] <petev> ok, but what if you were dealing with really complex system with large ASICs?
[07:46:38] <petev> would that bother you?
[07:46:38] <jmkasunich> at the device terminals, yes... inside the device I'm walking on thin ice
[07:46:43] <jmkasunich> yes
[07:46:55] <petev> hmm, not sure how to fix that one
[07:47:15] <petev> at some point you just have to have faith in the interface and go with it
[07:47:28] <jmkasunich> I can deal with high level stuff if it is reasonably transparent
[07:47:41] <jmkasunich> IOW, if I know that I can dive down inside if needed
[07:47:56] <petev> you have to get over that
[07:48:27] <petev> I deal with stuff where I have to sign NDAs just to see the interface and even that takes months to get through legal
[07:48:41] <petev> there's no way I get to know what happens under the hood
[07:48:48] <jmkasunich> so what happens when the interface doesn't work as promised?
[07:48:52] <petev> but I have to design with the stuff
[07:49:03] <petev> then you have to talk to the guy on the other side
[07:49:10] <petev> you debug at the interface level
[07:49:15] <petev> you both meet there
[07:49:42] <jmkasunich> I have that with the software guys
[07:50:05] <jmkasunich> usually I'm the guy under the hood
[07:50:11] <petev> so what happens there? do they let you review their code?
[07:50:20] <jmkasunich> depends on which ones
[07:50:41] <petev> if they do, they are pretty nice or have confidence
[07:50:51] <petev> most guys wouldn't want you looking at it
[07:50:52] <jmkasunich> we have some in our group, and they do (in fact, Monday we were trying to find an elusive problem, and I spotted the bug)
[07:51:22] <petev> most guys I have worked with are too insecure for that
[07:51:28] <petev> you must have a good team
[07:51:29] <jmkasunich> don't get me wrong - I am damned good at flipping up and down the levels of abstraction ;-)
[07:51:53] <petev> sure, but sometimes it's just no feasible or possible
[07:51:56] <jmkasunich> maybe thats why I don't like it when I'm prevented from doing so
[07:52:06] <petev> you should still be able to function
[07:53:08] <petev> the old days are gone, when a couple of guys could build a product in short order from the ground up and compete with the big boys
[07:53:38] <petev> sometimes I wish things were still simple as I liked working on the whole system
[07:53:45] <jmkasunich> think about it though - many many bugs are a single line of code somewhere... what is debugging except being able to go from a high level of abstraction "the drive trips on hi bus when we start it with reduced current loop gains" to low level where the code is "the initial value used for the Vd command in the inner current loop is wrong, and causes a transient at startup:
[07:53:57] <petev> but if you treat the big blocks as black boxes, it's almost the same
[07:54:29] <petev> it's just that now I have more complex building blocks and can build much more complex products in the same amount of time
[07:55:00] <jmkasunich> yeah - that is the part that makes me feel like a dinosaur
[07:55:12] <petev> what used to take a board is now on a single chip
[07:55:14] <jmkasunich> I'll build something that I know inside and out, and can dive into an fix
[07:55:29] <jmkasunich> in the same time, you'll build 10 products out of black boxes
[07:55:45] <petev> yeah, but you could do the same if you trust the blocks
[07:55:46] <jmkasunich> and if the box makers keep their side of the bargain, you'll never have to dive into them
[07:55:50] <petev> it's not that hard
[07:56:06] <petev> you trust the discretes on the physical level for the most part
[07:56:13] <jmkasunich> except my experience is that you can never trust the boxes
[07:56:29] <petev> It's not all that bad
[07:56:53] <petev> sure there are a few bugs in early silicon, but it's not usually a show stopper
[07:56:54] <jmkasunich> nah... I've seen capacitors that don't capacitate, resistors that don't resist, etc, etc... ;-)
[07:57:19] <petev> and they weren't one off bad parts?
[07:57:27] <petev> that would be pretty bad
[07:57:48] <jmkasunich> sometimes one-off bad parts, but they are still failures, and still need to be dealt with
[07:58:08] <jmkasunich> other times, parts that have some obscure limit, not in the data sheet, that makes them fail in my application
[07:58:23] <petev> true, but this is more of a manufacturing problem rather than design
[07:58:46] <petev> ahh, so you are sometimes working where specs don't exist
[07:58:51] <petev> well that would be tough
[07:58:55] <jmkasunich> all the time
[07:59:33] <jmkasunich> example: normal IGBT switching involves dV/dT of about 20KV/uS
[08:00:05] <jmkasunich> we found that a 450A IGBT module, when switching at 3 amps, could generate dV/DT of over 100KV/uS
[08:00:32] <jmkasunich> since we make AC drives, and the current is a sine wave that passes thru zero, it will switch at 3 amps sooner or later
[08:00:54] <jmkasunich> the opto-couplers used for gate drive are spec'ed to handle dV/dT of 25KV/uS
[08:01:06] <petev> was the device characterized at 450 A and it was just wrong, or were you using it in a range where it was not characterized?
[08:01:16] <jmkasunich> prior to our discovery, even the makers of the IGBT didn't know it could switch that fast
[08:01:44] <jmkasunich> it only happens at low current, and only if it hasn't been fully turned on before you turn it off
[08:01:52] <petev> hmm, it's tough to desing in areas where the device isn't characterized
[08:02:09] <jmkasunich> in the analog and especially the power world, it is impossible to characterise everything
[08:02:14] <petev> now I can see why you always want to peek under thehood
[08:03:32] <jmkasunich> we had engineers from the IGBT manufacturer over here and everything, because we were blowing up drives... eventually we changed the gate resistor, and it stopped happening.. .but nobody, including the PHDs at the vendor, really knows why they were failing, and why the aren't now
[08:03:39] <jmkasunich> we have theories, but no proof
[08:03:58] <petev> that's tough
[08:04:07] <Jymmm> jmkasunich no y-flux capacitor =)
[08:04:26] <petev> well, what do you think about the QT license issue?
[08:04:42] <jmkasunich> don't know enough to comment intelligently about it
[08:04:43] <petev> is it a show stopper for QT?
[08:05:00] <petev> basically a license is required for commercial use
[08:05:07] <petev> it's free for open source
[08:05:29] <jmkasunich> I guess it depends on how we use it
[08:05:58] <petev> I'm just trying to determine if it's worth working on some NML classes for QT and some QT widgets
[08:06:34] <jmkasunich> for instance, the VCP thing will be GPL code. It will read a file to set up a panel. There will be no "integrator written" code as part of the panel, so no proprietary code ever gets linked with QT, even if the user is designing a proprietar panel
[08:06:43] <jmkasunich> the only thing that is proprietary is the config file
[08:06:53] <petev> agreed
[08:07:14] <petev> but a QT GUI would require a license for commercial use
[08:07:28] <jmkasunich> but if a user actually builds an executable that contains proprietary code (logic for instance) it is a problem
[08:08:13] <jmkasunich> I am not a lawyer (thank god), so I avoid such discussions like the plague
[08:08:14] <petev> I think that if any proprietrary code gets used with QT, it has to be open source or you have to buy a QT license
[08:08:31] <jmkasunich> since I don't do C++, its a non-issue for me - I use GTK
[08:08:38] <petev> yeah, maybe I'll just do it, as I don't see another alternative that looks as good
[08:08:54] <petev> yep, but if you have to use NML that's an issue
[08:09:12] <jmkasunich> I'm only writing the VCP part, that is HAL only
[08:09:19] <petev> also, GTK goes through great pains to do what is handled very nicely by C++
[08:09:26] <jmkasunich> somebody else gets to do the NML ;-)
[08:09:28] <petev> understood
[08:09:45] <petev> yep, probably me since I want a better GUI
[08:09:58] <petev> I don't know how these other guys are happy
[08:09:59] <jmkasunich> sorry
[08:10:19] <petev> I want a MPG, cycle start/stop, etc.
[08:10:30] <petev> I think this is normal stuff to want
[08:10:31] <jmkasunich> some are, some aren't (happy)
[08:10:52] <jmkasunich> since few if any can do anything about it, they put up with it
[08:10:53] <petev> some think the current GUIs are great and we don't need to do more
[08:11:21] <petev> I think they must be playing with toys to have that opinion
[08:11:28] <petev> tkemc comes the closest by far
[08:11:35] <petev> but tool setup is a pain
[08:11:45] <petev> the hidden pop up dialogs suck
[08:12:01] <petev> yes, I see it
[08:12:16] <petev> but I can't reply
[08:12:35] <petev> I get some error about not being registered
[08:12:51] <petev> yes, but I can't reply
[08:12:55] <jmkasunich> ok
[08:13:04] <petev> alex sent private msg and it worked fine
[08:13:13] <petev> not sure why yours doesn't
[08:13:25] <petev> not much
[08:13:26] <jmkasunich> strange
[08:13:51] <petev> here's what I get on reply
[08:14:10] <petev> really
[08:14:15] <petev> how do I register?
[08:14:22] <petev> that should fix the error
[08:14:32] <Jymmm> jmkasunich /ns set unfiltered on
[08:14:52] <petev> still didn't work
[08:14:58] <petev> I'm EECS as well
[08:15:29] <petev> but do work from ASICs to emmbedded apps
[08:15:32] <Jymmm> petev because jmkasunich didnt enter that command
[08:16:17] <petev> hang on, I'm going to try and register
[08:17:19] <jmkasunich> I did the command: -NickServ- Toggled UnFiltered [ON]
[08:17:53] <Jymmm> then anyone unregistered can /msg you now.
[08:25:56] <Jymmm> and for a lack of a response, I suspected it worked =)
[08:26:09] <jmkasunich> yep
[08:26:20] <jmkasunich> either that or pete was able to register
[08:27:01] <Jymmm> that too
[09:36:38] <jmkasunich> jmkasunich is now known as jmk_sleep
[10:37:27] <petev> petev is now known as petev_
[10:37:41] <petev_> petev_ is now known as petev