Back
[12:41:50] <SteveStallings> SteveStallings is now known as steves_logging
[16:17:37] <ries_> ries_ is now known as ries
[18:31:08] <andypugh> I think I am in need of design direction.
[18:31:58] <andypugh> Currently the Mesa sserial driver (8i20 and 7i64) works well for normal use.
[18:34:06] <andypugh> If you add the modparam "sserial_setup" then you do not get the normal pins for the cards, you get a set of setup pins rather like the existing "raw_mode" where you can set a parameter address and value and then toggle a pin to read or write it.
[18:35:39] <andypugh> The thing is, this isn't all that much use. As you then have to stop the Mesa driver and restart in non-setup mode to use the new values (and if you power-latch the card they go back to default)
[18:36:46] <andypugh> I can't decide whether to make setup mode available all the time, so that you can peek and poke the values from HAL, or whether to remove it altogether and leave the driver more "normal"
[18:38:54] <andypugh> Setting the NVRAM values is a different sort of thing, and shouldn't really be in a hal component as it should be a set-once set of options, there is a risk of wiping the card firmware and the EEPROM has a finite life.
[18:40:43] <andypugh> I think it would be possible to do the load, set values, unload, reload cycle in a HAL file, but it seems inelegant.
[18:41:56] <andypugh> An alternative would be a userspace component that reads a config file and runs before the hm2_ driver, sets the values then quits to allow the hal file execution to continue.
[18:43:42] <mhaberler> where do I find a description of the python emc stat structure fields?
[18:44:00] <andypugh> As an other alternative, I could make a list of all the parameters that are likely to need to be set by the user and make them all HAL pins, specifying that the sserial port needs to be cycled between "run" and "stop" to update the values. This idea is growing on me.
[18:47:24] <andypugh> Perhaps this is a question better suited to the mailing list.
[18:48:58] <micges> mhaberler: source code
[19:18:10] <SWPadnos> andypugh, depending on what settings need to be set up (number of bits to transfer, clock polarity, misc. chip select options, etc.), the settings should be either load time parameters or HAL pins
[19:18:37] <SWPadnos> the driver can check for changes and update whenever a pin changes, and/or you can use a latch pin as you mentioned
[19:19:47] <andypugh> The whole port needs to stop to make a change to a connected device, I think.
[19:19:58] <SWPadnos> the opposite of a latch (a "hold" pin) would allow the user to make many changes without updating every time, and then during normal operation would still allow for instant changes later on
[19:20:13] <andypugh> The sorts of parameters I am talking about are max_current, pid_gain, that sort of thing.
[19:20:27] <SWPadnos> sure, if there is a sequence that needs to be followed or data may be invalidated or something, then a latch pin makes sense
[19:20:31] <SWPadnos> ah, ok
[19:20:52] <SWPadnos> I thought PCW said something about those changes not being immediate or something ...
[19:21:04] <SWPadnos> (I could be mistaken, I was only reading with one eye :) )
[19:21:09] <andypugh> And there is a fair bit of handshaking to and fro for each change.
[19:21:31] <psha> mhaberler: i think i have an hour to spend on glib hal bindings :)
[19:22:53] <mhaberler> well.. it's ok for a start.
[19:22:55] <mhaberler> that param pasing by globals.. ugly. maybe we need to wrap into a class.
[19:22:57] <andypugh> The NVRAM changes need a restart, the other changes are lost with a restart.
[19:23:25] <psha> mhaberler: surely you have
[19:23:56] <mhaberler> not yet..
[19:24:16] <psha> mhaberler: just create object and 'export' methods via 'on_click = obj.on_clik'
[19:25:28] <psha> andypugh: per you request we'd moved here :-P
[19:26:04] <mshaver> Can someone correct me if I am wrong: "A system installed from the 'official EMC2' CDROM will _not_ prompt users to upgrade their distribution (breaking the realtime system)."
[19:26:58] <andypugh> As max current is already handled (up to the nvram limit) I am rather tempted just to dump the parameter setting stuff and try to persuade Chris Morley to put the NVRAM parameter setting in pncconf (after all, that already has userspace access to the Mesa cards, I think?)
[19:27:31] <andypugh> psha: I am not in a position to request that anyone move, it was nothing more than a suggestion.
[19:27:57] <mhaberler> psha: where do I do the instantiation? in the handler, or blindly in gladevcp?
[19:28:09] <mhaberler> handler.py I meant
[19:28:15] <psha> andypugh: i'm just kidding :)
[19:28:36] <dgarr> mhaberler: where do I find a description of the python emc stat structure fields? start python in a shell try
[19:29:01] <dgarr> >>>help(emc.stat)
[19:29:24] <psha> mhaberler: i think yes, in handler
[19:30:02] <psha> maybe it's better to do it in init func
[19:30:39] <psha> so policy would be: if there is init function -- eat it's output as handler dict/object, if not - treat module as handler object
[19:30:58] <mhaberler> dgarr: I see these fields. I'm trying to find the underlying struct so I get can relate to their meaning, also for interp_state
[19:31:31] <mhaberler> psha: you mena module init, right
[19:33:50] <mhaberler> psha: I'm currently fighting the interpreter and not gladevcp; I'll push, maybe you see a solution
[19:35:32] <psha> let's see
[19:36:09] <mhaberler> old on.. this eclipse git thingy leaves to be desired
[19:41:00] <mhaberler> psha: snapshot is up in gladevcp-halpinhooks
[19:41:18] <psha> ok
[19:42:12] <mhaberler> psha: run with axis_gvcp_toolchanger.ini
[19:46:21] <psha> mhaberler: you've added too much...
[19:46:39] <mhaberler> psha: so?
[19:46:58] <psha> you've commited lib/python/touchy :)
[19:47:16] <mhaberler> parts thereof
[19:48:10] <psha> but forgot core_sim.hal
[19:48:58] <mhaberler> I'm losing you
[19:49:27] <mhaberler> why woudl that be needed?
[19:49:39] <psha> axis_gvcp_toolchanger.ini wants it
[19:51:00] <mhaberler> axis_gvcp_toolchanger.ini line 143?
[19:51:35] <psha> dunno, i've run emc axis_gcpc... and it tells me that it wants core_sim.hal
[19:54:30] <mhaberler> I see. hold on
[20:00:34] <mhaberler> gitignore was here. fixed.
[20:03:49] <SWPadnos> mshaver, a system installed from the EMC2 liveCD won't prompt for "standard" kernel updates, but will prompt when there are updates to our RTAI kernel
[20:18:36] <mshaver> SWPadnos: How about upgrades to the distribution. Would a Hardy system prompt you to upgrade to Lucid?
[20:19:00] <SWPadnos> possibly. it depends on the settings in update manager
[20:19:14] <SWPadnos> I'm not sure what else it depends on :)
[20:20:46] <mshaver> Do you know what they were in hardy? I looked in my Lucid system and it is set to "Long term support releases only" while it should probably be set to "Never".
[20:32:04] <psha> mhaberler: i've failed to run it :) too many absolute names to fix :)
[20:32:26] <psha> mhaberler: not only my home is /home/psha but emc2-dev is not in home directly!
[20:32:29] <psha> :)
[20:33:14] <psha> mhaberler: btw merge gladevcp-glade branch, it has fixed update thread
[20:33:22] <psha> i'll be back tomorrow :)
[20:33:37] <mhaberler> fair enough; maybe we retry when this is more cleaned up.
[20:33:39] <mhaberler> what was the problem with update thread?
[20:46:27] <andypugh> Is there a private messaging system on LinuxCNC.org? I have a curious email from someone.
[20:48:57] <micges> via forum only
[20:59:18] <andypugh> OK, it could be that, I am moderately active there.
[21:01:14] <cradek> andypugh: and thanks for that
[21:31:10] <JT-Hardinge> andypugh: you can click on a users name and send them an email but they don't see your email address
[21:31:46] <andypugh> I have received an email asking to communicate by PM.
[21:32:08] <andypugh> I am trying to decide whether to ignore him as a spammer, or sggest he try IRC.
[21:33:10] <jepler-> personally I prefer to conduct conversations about emc in private, because when I do answer someone's question I hope that the answer will ultimately benefit more than one person.
[21:33:17] <jepler-> if I do it in private, that's virtually guaranteed not to happen.
[21:33:21] <jepler-> jepler- is now known as jepler
[21:34:19] <andypugh> Do you mean !conduct?
[21:36:05] <jepler> right
[21:36:12] <jepler> prefer .. in public
[21:36:40] <JT-Hardinge> if you think he/she/it is a spammer let me know who it is and I can ban them
[21:37:40] <jepler> hm, I figured there would be a "don't let users contact me privately" checkbox in the account profile page on linuxcnc.org, but if it's there I'm overlooking it.
[21:37:46] <JT-Hardinge> yea, if they want a personal answer to an EMC question I send them back to the forum or mailing list or IRC
[23:58:34] <andypugh> For fun, and because I don't know where to go with the 8i20 driver, I am making the gearchange component handle more than 2 gears. In fact it can now have 32.
[23:59:00] <andypugh> (Is that enough?, it's an arbitrary limit)
[23:59:20] <andypugh> How careful do I need to be to preserve compatibility with the old version?