Back
[08:52:03] <mozmck> cradek: thanks for the statetags description. That's essentially what I had gathered but was not sure.
[09:28:56] <cradek> welcome
[09:29:11] <cradek> do you have a plan yet?
[09:46:16] <mozmck> Yeah, for now I think I'll just paper over it by not letting the line number go backwards until I get an interp_idle signal.
[09:47:25] <mozmck> This is one small issue and I have several others to work on. Later I need to look at state-tags and several other things.
[09:48:43] <mozmck> I think issue 177 is one that has affected some of our customers - so I need to look at that. It's critical because the TP goes back to making huge curves instead of sharp points and destroys material
[09:55:00] <cradek> hm I haven't tested estop in state tags - an aborter kind of abort
[09:56:38] <mozmck> issue 177 is in 2.7.x - I don't know if state-tags branch fixes that.
[09:57:29] <cradek> yeah, for better or worse, my own focus is more on master now
[09:59:40] <cradek> alex!
[10:08:51] <alex_joni> hi chris
[10:09:30] <alex_joni> changed some network cards on this PC, and remembered to start up screen ;)
[10:29:53] <cradek> this is super half-baked but I have an idea
[10:30:17] <cradek> er, forget it
[10:30:29] <cradek> my idea doesn't handle a case we already know about
[10:30:37] * cradek waves his arms
[10:33:03] <cradek> (I was thinking of the gui configurator having a dummy hal engine that would let components execute things up to hal_ready(), taking notes about which pins and params are created, but not requiring a real hal invocation or interacting with any running hal)
[10:34:36] <cradek> this would handle tricky cases that depend on arguments/config strings to decide what pins to present
[10:34:52] <cradek> but it doesn't solve the sserial/pico systems that probe for the attached hardware
[10:36:42] <alex_joni> why not use the real hal?
[10:36:53] <alex_joni> and just not run start
[10:37:00] <cradek> I think that's going to be the only realistic way
[10:37:38] <cradek> I was hoping to have it independent of any actual running system, and of the kernel stuff etc
[10:37:56] <cradek> sometimes it bugs me that I can't run the tests when linuxcnc is running
[10:38:00] <cradek> this would be the same kind of limitation
[10:38:45] <alex_joni> I don't think it's realistic to expect to simulate all possible combinations users will come up with
[10:39:14] <cradek> right
[10:40:34] <cradek> but just like AXIS has a canon interface that doesn't generate motion, it seems like you could have a dummyhal library that would present the hal newpin etc functions and just learns from their calls
[10:45:46] <archivist> I think a real probe and hal is the only way, also reading and writing the actual hal file not overwriting it from some other file that noobs get caught out by
[10:51:59] <mozmck> My thought is that there could be some description file for each HAL component which the configurator could read. The user would have to know all the hardware that would be attached and select it, but then the description files would give all the needed information for that hardware.
[10:53:06] <mozmck> Of course those files would need to be updated with any component changes.
[10:53:15] <archivist> descripter files cannot/wont work for the live pin readers
[10:53:22] <mozmck> why?
[10:53:49] <mozmck> the hardware attached via sserial will always be known to the system designer won't it?
[10:53:55] <archivist> because the available pins are named and made available at run time
[10:54:50] <mozmck> Yeah, but you know what you have attached before you turn it on. So you tell the configurator that, and it adds the HAL information for that hardware.
[10:56:05] <archivist> not quite, as the scan may find device one or two and name as it sees fit
[10:56:48] <mozmck> Surely it's not random...
[10:57:33] <archivist> not random but variable with bit file etc
[10:59:04] <mozmck> Yes, so there would need to be a hardware description file for each bitfile. The configurator can also be made smart enough to load the right bitfile (for Mesa boards) depending on the hardware selected.
[11:02:45] <archivist> if done by reading the live hal mistakes are impossible due to people setting stuff incorrectly or using outdated config files
[11:03:05] <mozmck> That's true.
[11:03:39] <cradek> that's the solution that works for all past and all future components (no matter how weirdly they configure themselves) at once with no extra work/maintenance
[11:03:42] <mozmck> So I guess the idea is to have the user select the hardware, then load the hal drivers and probe?
[11:03:56] <cradek> for that reason we should very strongly prefer it if possible
[11:05:11] <cradek> writing and maintaining a separate description for each one is one step worse, and something like stepconf which tries to know already what hal components you might want and how they'll be connected is two steps worse
[11:05:53] <cradek> (I don't know enough about pncconf to know which step it's at)
[11:05:54] <mozmck> yeah, makes sense. Using HAL and probing may take a lot more user input though.
[11:06:45] <cradek> yeah I can't really picture a full workflow yet
[11:06:59] <archivist> well, some choice of mesa/parallel/pru I would expect so the right probing can be done
[11:07:17] <cradek> the gui would ideally help somehow with the step where you futz with the loadrt commandline until it loads right and presents the pins you want
[11:07:43] <archivist> I can see some noobs confused by that
[11:07:47] <mozmck> And I wonder how much easier it will really be? It seems to me that it would be good to hide a lot of little HAL details.
[11:08:35] <cradek> yeah it'd be tempting to build in details about particular kinds of hardware (like let you run mesaflash) but then you start going wrong and having a pncconf style nightmare
[11:08:54] <archivist> a tree of questions to get the basic hal right for a stepper/servo then a probe of hardware pins
[11:09:18] <cradek> starting samples maybe
[11:09:36] <cradek> I'd like it if it was generic enough that it could configure hal in ways other than for linuxcnc
[11:09:55] <mozmck> Yeah, both of those would help. And having all the params and pins shown for a component also helps.
[11:10:01] <archivist> could be, jt was working on something too, but keeping quiet at the moment :)
[11:10:04] <cradek> otherwise we're reinventing stepconf/pncconf a third time
[11:10:53] <mozmck> Yeah, it needs to have a very flexible design. JT better hurry!
[11:12:21] <mozmck> Another problem with probing hardware is you have to have the hardware and have it all connected for that to work.
[11:13:00] <cradek> very true
[11:13:06] <cradek> and you have to work right at the machine
[11:13:49] <mozmck> I guess once a config is made though, you could load it and modify without the hardware connected if things are done correctly.
[11:15:16] <mozmck> heh, you could even do auto-probing and figure out what hardware is connected without the user even having to tell it.
[11:15:57] <jepler> not really
[11:16:11] <jepler> think mesa ethernet, where you have to give an IP address
[11:16:58] <mozmck> Yeah, and no broadcast support right now. You could probe 192.168.1.121 and 10.10.10.10 and probably catch 99% of the cards though.
[11:17:44] <pcw_home> v16 firmware supports broadcast
[11:17:56] <cradek> it seems easier to view/edit an existing configuration than to generate one from nothing
[11:18:28] <cradek> and it would be stupid to make a user start from scratch and hook up all the pids and motion pins and all that
[11:18:54] <jepler> I just hope I never make the mistake of writing a GUI configurator for end users ever again
[11:20:03] <jepler> but anyway, if you look at schematic capture software, you will QUICKLY learn that aside from very boring stuff like pin headers you will NEVER want a symbol that is autogenerated from a flat list of pin names
[11:20:36] <seb_kuzminsky> pcw_home: once it supports multicast you can use mdns/sd to discover the connected cards with standard tools
[11:21:28] <pcw_home> if the structural hal parts are separated from the hardware names and gui interface bits there probably are not that many basic hal files
[11:23:41] <pcw_home> It supports broadcast only (so a broadcast read cookie will get replies from all within the netmask range)
[11:24:02] <pcw_home> broadcast ping also
[11:25:13] <mozmck> cradek: that's why my thought was to have a description file for each hardware/bitfile etc. It would be a bit of a pain to write up front, and then maintain, but would make initial setup easier. Another option would be to simply have sample configs or templates for various hardware setups.
[11:25:58] <cradek> I'm starting to believe you
[11:26:09] <mozmck> although templates for hardware setups might not really be any different than hardware description files in practice. They have to be written and then maintain if hardware/drivers change.
[11:26:15] <cradek> a part library like eagle has
[11:26:28] <cradek> manufacturers could provide the library for their products
[11:26:28] <mozmck> basically yes.
[11:26:40] <mozmck> that was my thought exactly.
[11:26:55] <mozmck> Or someone else could do it too if they wanted.
[11:27:27] <pcw_home> I dont like the turn of this conversation, looks like work...
[11:27:52] <mozmck> I have written a configurator for our hardware and setups, and have given some thought to making something more generic.
[11:28:10] <jepler> good symbols are going to be work
[11:28:17] <mozmck> pcw_home: :-) That's why I mentioned someone else could do it too ;-)
[11:28:19] <jepler> absolutely
[11:31:07] <mozmck> One advantage of hardware description files; is that if done in something human readable it would basically keep documentation up to date.
[11:32:11] <mozmck> Maybe even write them as manpages?
[11:32:58] <cradek> I agree with your vision of writing the description once and using it in several ways
[11:33:29] <cradek> sort of how comp generates a basic manpage
[11:33:42] <cradek> it could also create a basic part library item
[11:34:01] <cradek> a rectangle with the ins on the left and the outs on the right
[11:35:59] <jepler> as I said on the mailing list, I'm not against halcompile being enhanced like this
[11:38:23] <KGB-linuxcnc> 03Norbert Schechner 052.7 a0fd4d9 06linuxcnc 10src/emc/usr_intf/gmoccapy/getiniinfo.py 10src/emc/usr_intf/gmoccapy/gmoccapy.py 10src/emc/usr_intf/gmoccapy/release_notes.txt gmoccapy_1_5_6_6 - check for INI entry DEFAULT_SPINDLE_SPEED * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a0fd4d9
[11:45:58] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 0076e56 06linuxcnc 10docs/src/getting-started/updating-linuxcnc.txt docs: punctuation fixes in Updating LinuxCNC * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0076e56
[11:56:21] <KGB-linuxcnc> 03Norbert Schechner 052.7 65ebb59 06linuxcnc 10docs/src/config/ini-config.txt documentation - INI File settings added some gmoccapy stuff * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=65ebb59
[11:56:21] <KGB-linuxcnc> 03Norbert Schechner 052.7 153a66e 06linuxcnc Merge branch '2.7' of ssh://norbert@git.linuxcnc.org/git/linuxcnc.git into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=153a66e
[13:08:52] <seb_kuzminsky> the jessie armhf buildslave crashed again
[13:09:25] <seb_kuzminsky> i should try switching which U3 is wheezy & which is jessie, to see if the problem is with the U3 or the distro...
[13:23:31] <jepler> seb_kuzminsky: just a swap of an SD or e-mmc? go for it
[17:58:05] <pcw_mesa> hmm what would cause a "missing symbol in module error" in hm2_pci.ko thats dependent on hal/ini contents
[17:58:48] <jepler> pcw_mesa: failure to loadrt hostmot2 above loadrt hm2_pci ?
[18:04:38] <pcw_mesa> yep, sorry
[18:06:13] <pcw_mesa> trying to debug terakaa's SSI issue, and stripped a bit too much out of the source hal file to make my test file
[18:30:29] <cradek> pcw_mesa: I think when that happens, dmesg tells you the missing symbol
[19:00:41] <pcw_mesa> Yeah it did, i just did not know what it meant (i think hm2_register and hm2_unregister were missing)
[22:20:32] <pcw_home> Naturally I cannot duplicate the SSI errors... sigh