Back
[00:15:03] -!- skunkworks_ [skunkworks_!~skunkwork@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[00:29:04] -!- kingarmadillo has quit [Ping timeout: 260 seconds]
[00:40:52] amnesic_away is now known as amnesic
[01:37:44] -!- kingarmadillo has quit [Ping timeout: 260 seconds]
[01:42:54] nima is now known as Guest21904
[01:43:36] Guest21904 is now known as NimaBoscarino
[02:05:50] -!- NimaBoscarino has quit [Remote host closed the connection]
[02:20:18] <cradek> mozmck: no docs, but the summary is: attach to moves a summary of the interpreter state (like the line number has been attached for a while) and do two things with it: show the active gcodes from those tags as the moves execute, AND in the case of abort, use the latest tag to restore the interp state as if readahead had not happened
[02:21:27] <Tom_L> sounds like a good thing
[02:21:33] <cradek> part 1 is the important one to you: just add the interp stack level to the tags
[02:21:41] <cradek> "just"
[02:22:11] <cradek> yeah it's a super good change
[02:22:29] <Tom_L> will be able to run from line better etc
[02:22:46] <Tom_L> is that the idea?
[02:22:53] <cradek> it sure might help with that
[02:23:20] <cradek> I think the idea was keep users from being baffled by readahead
[02:23:31] <Tom_L> andy's tool table sounds good too
[02:23:36] <cradek> it makes things seem weird in a lot of ways
[02:23:41] <cradek> yes it sure is
[02:24:01] <Tom_L> did he make it to the fest?
[02:24:07] <cradek> wish the bikeshedders would leave him alone
[02:24:21] <cradek> not this time, saw him 2? yrs ago though
[02:24:28] <Tom_L> yeah something like that
[02:24:49] <Tom_L> bikeshedders?
[02:24:58] <Tom_L> someone buggin him on the forum?
[02:25:32] <cradek> google bikeshedding as regards software development, I'm on a phone or I'd do it for you
[02:25:41] <Tom_L> k
[02:26:05] <cradek> teeny tiny keyboard
[02:26:18] <Tom_L> yeah i hate phones for that
[02:26:25] <Tom_L> found it
[02:27:00] <cradek> did you find the original freebsd mailing list post?
[02:27:03] <Tom_L> nit picking
[02:27:31] <Tom_L> to a fault
[02:28:12] <cradek> yeah, having an opinion about unimportant decisions and getting in the way of talking about the important
[02:28:25] <cradek> we all do it :-/
[02:28:38] <Tom_L> some catch it quicker than others
[02:28:42] -!- jbr has quit [Quit: ChatZilla 0.9.92 [Firefox 49.0.2/20161019084923]]
[02:30:37] <cradek> it helped me to learn about the pattern so I can squash it in myself
[02:30:53] <cradek> because it's a very real effect and it's destructive
[02:31:01] <Tom_L> yup
[02:31:21] <Tom_L> i believe it caused the split 2 yrs ago
[02:31:35] <Tom_L> possibly
[02:32:06] <Tom_L> there may have been more to that
[02:32:12] <cradek> I don't really agree with you, but you may be a few % right
[02:32:36] <Tom_L> some saw things differently i guess
[02:32:56] <cradek> I think that split has been good for everyone
[02:32:57] <Tom_L> i really haven't followed the other project at all
[02:33:33] <cradek> I hope it's thriving too
[02:33:39] <Tom_L> so do i
[02:33:48] <Tom_L> it can only help everyone i think
[02:34:49] <cradek> two machinekit guys were at fest, and it was great to see them
[02:35:05] <Tom_L> mharbler one of em?
[02:35:20] <Tom_L> he's really the only one i knew of
[02:35:24] <cradek> nope
[02:38:24] -!- kingarmadillo has quit [Ping timeout: 260 seconds]
[02:48:07] amnesic is now known as amnesic_away
[03:07:44] -!- Einherjer has quit [Ping timeout: 256 seconds]
[03:12:17] -!- NimaBoscarino has quit [Remote host closed the connection]
[03:13:21] -!- skunksleep [skunksleep!~AndChat14@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[03:14:24] <skunksleep> cradek: I assume you met the guy that goes by dragon?
[03:14:42] <skunksleep> Sounded like he went to the fest
[03:16:21] <skunksleep> He is from around here. We had a mini fest at the shop a few years ago and the local Linux group came. He is a member. (I still need to go to a meeting)
[03:32:30] <cradek> yes I think dragon is todd, who we talked a lot with
[03:33:00] <cradek> he wants to make lathe roughing cycles and I think he's smart enough to do it
[03:39:06] -!- kingarmadillo has quit [Ping timeout: 250 seconds]
[03:53:23] -!- KimK has quit [Ping timeout: 245 seconds]
[04:06:48] -!- KimK [KimK!~Kim__@2600:8803:7a85:6d00:881f:b8fa:247:f424] has joined #linuxcnc-devel
[04:15:31] -!- miek__ [miek__!uid193868@gateway/web/irccloud.com/x-kmfsmfbjdiqfaytu] has joined #linuxcnc-devel
[04:42:32] -!- kingarmadillo has quit [Ping timeout: 260 seconds]
[05:06:05] -!- kwallace_ofcb [kwallace_ofcb!~kwallace@162.222.30.253] has parted #linuxcnc-devel
[05:43:36] -!- kingarmadillo has quit [Ping timeout: 260 seconds]
[06:44:11] -!- kingarmadillo has quit [Ping timeout: 244 seconds]
[07:03:49] -!- NimaBoscarino has quit [Remote host closed the connection]
[07:06:12] -!- kingarmadillo has quit [Ping timeout: 260 seconds]
[07:08:41] -!- NimaBoscarino has quit [Ping timeout: 256 seconds]
[08:07:03] -!- kingarmadillo has quit [Ping timeout: 256 seconds]
[08:49:26] -!- Khetzal has quit [Remote host closed the connection]
[08:55:02] -!- Khetzal [Khetzal!~khetzal@sierra.khetzal.info] has joined #linuxcnc-devel
[09:07:18] -!- kingarmadillo has quit [Ping timeout: 244 seconds]
[09:21:44] -!- M-IvanSanchez has quit [Remote host closed the connection]
[10:08:14] -!- pozzoni has quit [Ping timeout: 250 seconds]
[10:19:23] amnesic_away is now known as amnesic
[10:19:47] jthornton- is now known as jthornton
[11:09:31] -!- NimaBoscarino has quit [Ping timeout: 256 seconds]
[11:23:52] -!- KimK has quit [Quit: Leaving]
[11:31:04] -!- KimK [KimK!~Kim__@2600:8803:7a85:6d00:69a1:e009:d9b5:22d] has joined #linuxcnc-devel
[11:37:59] -!- kalxas has quit [Changing host]
[11:38:22] -!- pozzoni has quit [Ping timeout: 250 seconds]
[11:39:41] amnesic is now known as amnesic_away
[11:50:12] -!- skunksleep has quit [Read error: Connection reset by peer]
[12:20:44] -!- KimK_laptop has quit [*.net *.split]
[12:36:21] -!- KimK_laptop [KimK_laptop!~Kim@helixmachine.com] has joined #linuxcnc-devel
[12:59:32] amnesic_away is now known as amnesic
[13:08:15] -!- M-IvanSanchez has quit [Remote host closed the connection]
[13:14:13] -!- pragmaticus has quit [Ping timeout: 245 seconds]
[13:23:46] <mozmck> cradek: thanks for the statetags description. That's essentially what I had gathered but was not sure.
[13:35:53] -!- kingarmadillo has quit [Ping timeout: 245 seconds]
[13:56:10] -!- kingarmadillo has quit [Ping timeout: 250 seconds]
[14:00:39] <cradek> welcome
[14:00:54] <cradek> do you have a plan yet?
[14:09:06] -!- b_b has quit [Changing host]
[14:17:58] <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.
[14:19:07] <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.
[14:20:25] <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
[14:26:43] <cradek> hm I haven't tested estop in state tags - an aborter kind of abort
[14:28:20] <mozmck> issue 177 is in 2.7.x - I don't know if state-tags branch fixes that.
[14:29:12] <cradek> yeah, for better or worse, my own focus is more on master now
[14:31:14] -!- alex_joni [alex_joni!~alex_joni@emc/board-of-directors/alexjoni] has joined #linuxcnc-devel
[14:31:14] -!- mode/#linuxcnc-devel [+v alex_joni] by ChanServ
[14:31:23] <cradek> alex!
[14:40:34] <alex_joni> hi chris
[14:41:12] <alex_joni> changed some network cards on this PC, and remembered to start up screen ;)
[14:42:12] -!- kwallace_ofcb [kwallace_ofcb!~kwallace@162.222.30.253] has joined #linuxcnc-devel
[15:01:35] <cradek> this is super half-baked but I have an idea
[15:02:00] <cradek> er, forget it
[15:02:12] <cradek> my idea doesn't handle a case we already know about
[15:02:19] * cradek waves his arms
[15:04:45] <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)
[15:06:18] <cradek> this would handle tricky cases that depend on arguments/config strings to decide what pins to present
[15:06:35] <cradek> but it doesn't solve the sserial/pico systems that probe for the attached hardware
[15:08:25] <alex_joni> why not use the real hal?
[15:08:36] <alex_joni> and just not run start
[15:08:43] <cradek> I think that's going to be the only realistic way
[15:09:20] <cradek> I was hoping to have it independent of any actual running system, and of the kernel stuff etc
[15:09:38] <cradek> sometimes it bugs me that I can't run the tests when linuxcnc is running
[15:09:43] <cradek> this would be the same kind of limitation
[15:10:28] <alex_joni> I don't think it's realistic to expect to simulate all possible combinations users will come up with
[15:10:57] <cradek> right
[15:12:16] <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
[15:15:11] -!- Daerist has quit [Quit: Leaving]
[15:16:35] -!- skunkworks_ has quit [Ping timeout: 256 seconds]
[15:17:28] <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
[15:23:42] <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.
[15:24:49] <mozmck> Of course those files would need to be updated with any component changes.
[15:24:57] <archivist> descripter files cannot/wont work for the live pin readers
[15:25:04] <mozmck> why?
[15:25:32] <mozmck> the hardware attached via sserial will always be known to the system designer won't it?
[15:25:37] <archivist> because the available pins are named and made available at run time
[15:26:33] <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.
[15:27:48] <archivist> not quite, as the scan may find device one or two and name as it sees fit
[15:28:31] <mozmck> Surely it's not random...
[15:29:16] <archivist> not random but variable with bit file etc
[15:30:47] <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.
[15:34:27] <archivist> if done by reading the live hal mistakes are impossible due to people setting stuff incorrectly or using outdated config files
[15:34:47] <mozmck> That's true.
[15:35:22] <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
[15:35:24] <mozmck> So I guess the idea is to have the user select the hardware, then load the hal drivers and probe?
[15:35:39] <cradek> for that reason we should very strongly prefer it if possible
[15:36:53] <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
[15:37:35] <cradek> (I don't know enough about pncconf to know which step it's at)
[15:37:37] <mozmck> yeah, makes sense. Using HAL and probing may take a lot more user input though.
[15:38:28] <cradek> yeah I can't really picture a full workflow yet
[15:38:42] <archivist> well, some choice of mesa/parallel/pru I would expect so the right probing can be done
[15:38:59] <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
[15:39:26] <archivist> I can see some noobs confused by that
[15:39:29] <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.
[15:40:18] <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
[15:40:36] <archivist> a tree of questions to get the basic hal right for a stepper/servo then a probe of hardware pins
[15:41:01] <cradek> starting samples maybe
[15:41:19] <cradek> I'd like it if it was generic enough that it could configure hal in ways other than for linuxcnc
[15:41:37] <mozmck> Yeah, both of those would help. And having all the params and pins shown for a component also helps.
[15:41:44] <archivist> could be, jt was working on something too, but keeping quiet at the moment :)
[15:41:46] <cradek> otherwise we're reinventing stepconf/pncconf a third time
[15:42:36] <mozmck> Yeah, it needs to have a very flexible design. JT better hurry!
[15:44:03] <mozmck> Another problem with probing hardware is you have to have the hardware and have it all connected for that to work.
[15:44:42] <cradek> very true
[15:44:49] <cradek> and you have to work right at the machine
[15:45:32] <mozmck> I guess once a config is made though, you could load it and modify without the hardware connected if things are done correctly.
[15:46:58] <mozmck> heh, you could even do auto-probing and figure out what hardware is connected without the user even having to tell it.
[15:47:40] <jepler> not really
[15:47:54] <jepler> think mesa ethernet, where you have to give an IP address
[15:48:40] <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.
[15:49:27] <pcw_home> v16 firmware supports broadcast
[15:49:39] <cradek> it seems easier to view/edit an existing configuration than to generate one from nothing
[15:50:11] <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
[15:50:36] <jepler> I just hope I never make the mistake of writing a GUI configurator for end users ever again
[15:51:46] <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
[15:52:18] <seb_kuzminsky> pcw_home: once it supports multicast you can use mdns/sd to discover the connected cards with standard tools
[15:53:11] <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
[15:55:24] <pcw_home> It supports broadcast only (so a broadcast read cookie will get replies from all within the netmask range)
[15:55:45] <pcw_home> broadcast ping also
[15:56:55] <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.
[15:57:41] <cradek> I'm starting to believe you
[15:57:51] <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.
[15:57:57] <cradek> a part library like eagle has
[15:58:10] <cradek> manufacturers could provide the library for their products
[15:58:11] <mozmck> basically yes.
[15:58:22] <mozmck> that was my thought exactly.
[15:58:37] <mozmck> Or someone else could do it too if they wanted.
[15:59:10] <pcw_home> I dont like the turn of this conversation, looks like work...
[15:59:34] <mozmck> I have written a configurator for our hardware and setups, and have given some thought to making something more generic.
[15:59:52] <jepler> good symbols are going to be work
[15:59:59] <mozmck> pcw_home: :-) That's why I mentioned someone else could do it too ;-)
[16:00:01] <jepler> absolutely
[16:02:50] <mozmck> One advantage of hardware description files; is that if done in something human readable it would basically keep documentation up to date.
[16:03:54] <mozmck> Maybe even write them as manpages?
[16:04:41] <cradek> I agree with your vision of writing the description once and using it in several ways
[16:05:11] <cradek> sort of how comp generates a basic manpage
[16:05:24] <cradek> it could also create a basic part library item
[16:05:43] <cradek> a rectangle with the ins on the left and the outs on the right
[16:07:41] <jepler> as I said on the mailing list, I'm not against halcompile being enhanced like this
[16:10:05] <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
[16:17:41] <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
[16:28:04] <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
[16:28:04] <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
[16:40:04] -!- agoddard has quit [Read error: Connection reset by peer]
[16:41:35] -!- KimK has quit [Ping timeout: 256 seconds]
[16:41:36] -!- johtso has quit [Ping timeout: 256 seconds]
[16:41:36] -!- _fil_ has quit [Ping timeout: 256 seconds]
[16:42:10] -!- jmk-mcfaul_ has quit [Ping timeout: 256 seconds]
[16:42:43] -!- IvanSanchez[m] has quit [Ping timeout: 256 seconds]
[16:45:07] -!- jmk-mcfaul_ [jmk-mcfaul_!~jmkasunic@2602:306:37ea:8560:260:97ff:fe20:c59d] has joined #linuxcnc-devel
[16:45:44] -!- KimK [KimK!~Kim__@2600:8803:7a85:6d00:69a1:e009:d9b5:22d] has joined #linuxcnc-devel
[17:14:31] -!- pcw_home has quit [Ping timeout: 252 seconds]
[17:15:01] -!- pcw_home [pcw_home!~chatzilla@c-50-143-148-115.hsd1.ca.comcast.net] has joined #linuxcnc-devel
[17:18:32] -!- Connor has quit [Read error: Connection reset by peer]
[17:29:35] -!- Connor [Connor!~Connor@71.203.255.220] has joined #linuxcnc-devel
[17:37:54] -!- hm2-buildmaster_ [hm2-buildmaster_!~hm2-build@174-29-22-126.hlrn.qwest.net] has joined #linuxcnc-devel
[17:38:05] -!- linuxcnc-build_ [linuxcnc-build_!~linuxcnc-@174-29-22-126.hlrn.qwest.net] has joined #linuxcnc-devel
[17:40:28] -!- hm2-buildmaster has quit [Ping timeout: 245 seconds]
[17:40:35] <seb_kuzminsky> the jessie armhf buildslave crashed again
[17:40:38] -!- linuxcnc-build has quit [Ping timeout: 250 seconds]
[17:41:08] <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...
[17:55:14] <jepler> seb_kuzminsky: just a swap of an SD or e-mmc? go for it
[17:56:58] -!- IvanSanchez[m] has quit [Remote host closed the connection]
[18:24:33] -!- ve7it [ve7it!~LawrenceG@S010648f8b3c3bc3b.pk.shawcable.net] has joined #linuxcnc-devel
[19:22:16] -!- basiclaser has quit [Quit: Connection closed for inactivity]
[19:31:44] amnesic is now known as amnesic_away
[19:45:39] -!- b_b has quit [Remote host closed the connection]
[20:16:33] -!- pcw_mesa_ [pcw_mesa_!~chatzilla@99.88.10.65] has joined #linuxcnc-devel
[20:18:32] -!- pcw_mesa has quit [Ping timeout: 250 seconds]
[20:18:43] pcw_mesa_ is now known as pcw_mesa
[20:25:03] -!- GJdan has quit [Quit: WeeChat 1.7-dev]
[20:57:11] amnesic_away is now known as amnesic
[21:00:29] -!- skorasaurus has quit [Ping timeout: 260 seconds]
[21:47:20] -!- kingarmadillo has quit [Ping timeout: 260 seconds]
[22:13:06] -!- BeachBumPete [BeachBumPete!~IceChat9@2601:589:8201:bbc0:48db:826d:b1cb:2cd] has joined #linuxcnc-devel
[22:18:23] -!- BeachBumPete [BeachBumPete!~IceChat9@2601:589:8201:bbc0:48db:826d:b1cb:2cd] has parted #linuxcnc-devel
[22:29:47] <pcw_mesa> hmm what would cause a "missing symbol in module error" in hm2_pci.ko thats dependent on hal/ini contents
[22:30:31] <jepler> pcw_mesa: failure to loadrt hostmot2 above loadrt hm2_pci ?
[22:30:44] -!- andypugh [andypugh!~andypugh@cpc14-basl11-2-0-cust1010.20-1.cable.virginm.net] has joined #linuxcnc-devel
[22:36:21] <pcw_mesa> yep, sorry
[22:37:55] <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
[22:39:23] -!- pragmaticus has quit [Ping timeout: 252 seconds]
[22:52:43] -!- zeeshan [zeeshan!~kvirc64@CPE84948c379051-CM84948c379050.cpe.net.cable.rogers.com] has joined #linuxcnc-devel
[23:02:11] <cradek> pcw_mesa: I think when that happens, dmesg tells you the missing symbol
[23:32:24] <pcw_mesa> Yeah it did, i just did not know what it meant (i think hm2_register and hm2_unregister were missing)
[23:47:04] -!- Roguish_ [Roguish_!~chatzilla@c-50-143-183-159.hsd1.ca.comcast.net] has joined #linuxcnc-devel
[23:47:04] Roguish_ is now known as Roguish
[23:51:42] -!- skunkworks_ [skunkworks_!~skunkwork@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[23:58:42] -!- NimaBoscarino has quit [Quit: ChatZilla 0.9.92 [Firefox 51.0a2/20161027004020]]