Back
[07:29:18] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/hallib e0af21a 06linuxcnc 10(22 files in 7 dirs) sim/configs:use [HAL]HALFILE=LIB: (3 hallib items) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e0af21a
[10:21:46] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/hallib 0780025 06linuxcnc 10src/Makefile xhc-hb04: monitor-xhc-hb04 in bin dir for deb * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0780025
[13:58:46] <seb_kuzminsky> hi dgarr
[14:00:15] <dgarr> yo
[14:00:28] <seb_kuzminsky> i'm looking at the hallib branch
[14:00:34] <dgarr> ok
[14:00:44] <seb_kuzminsky> it's a good feature, but i have a suggestion for a change in how it's implemented
[14:01:26] <seb_kuzminsky> i'd like to see HALLIB_DIR handled more like LD_LIBRARY_PATH
[14:02:21] <seb_kuzminsky> ie, a set of directories that get searched when a hal file is requested
[14:03:08] <seb_kuzminsky> the default could be ".:$HALLIB_DIR", to look firs in the .ini directory, then in the system path ($EMC2_HOME/lib/hallib or ${prefix}/share/linuxcnc/hallib, as appropriate)
[14:04:27] <seb_kuzminsky> that way you wouldn't need to know where the halfile lived and prefix it with LIB: if it's a shared file
[14:08:04] <dgarr> ugh -- i can do that but my experience with users and [RS274NGC]SUBROUTINE_PATH and USER_M_PATH says that ambiguity or uncertainty in expressing a resource location is pretty new to many.
[14:08:29] <dgarr> i think a special LIB:file name that means just use what the system provides is much clearer and simpler
[14:10:05] <dgarr> for example, with the method i've done, i can say just add the lline HALFILE=LIB:hookup_moveoff.tcl and there will no confflict with a leift over file in an ini directory
[14:10:28] <seb_kuzminsky> yeah, i can see that argument
[14:11:55] <dgarr> plus when upgrades occur, use LIB:hookup_moveoff.tcl works and i don't have to ask did you copy the new file or check your derectory for another file with more precedence in the search path when the guy has never heard of a search path
[14:11:59] <seb_kuzminsky> the current hallib branch essentially makes it so "LIB:" in a [HAL]HALFILE name means one of those two paths above, depending on if it's run-in-place or not, right?
[14:12:52] <dgarr> like many tinks RIP and deb use different file paths, the LIB: spec will resolve correctly depending upon RIP or deb
[14:13:05] <dgarr> s/tinks/things/
[14:13:14] <seb_kuzminsky> yeah
[14:15:20] <dgarr> i dont' see a lot of upside for making it more complicated when its meant as a convenience for users and simplivication of adapting configurations
[14:15:31] <seb_kuzminsky> sure
[14:16:09] <seb_kuzminsky> to me it's simpler to have it work like other "look elsewhere for this file" mechanisms
[14:16:24] <seb_kuzminsky> but i understand that not all our users think that way
[14:17:27] <seb_kuzminsky> i dont feel strongly about it, it just struck me as surprising how it works
[14:17:30] <dgarr> For someone trying to assist someone the ambiguity of a search path makes for many more questions
[14:18:40] <seb_kuzminsky> if we have a HALPATH system instead of this hallib system, we could make scripts/linuxcnc report which path it found the hal file at
[14:19:08] <seb_kuzminsky> just like you currently do, i see
[14:19:10] <dgarr> it already reports where it found the file
[14:19:14] <seb_kuzminsky> right
[14:19:16] <pcw_home> could you leave the default path hardwired into the search path and then tack on an additional path list if the list file exists
[14:19:34] <dgarr> so if a user wanted to modify, he copies, removes the LIB: label and modifies his copy
[14:19:39] <dgarr> but beginners don't do that
[14:19:55] <seb_kuzminsky> pcw_home: that's not an option with hallib, but it would be an option with the HALPATH system we're discussing
[14:21:16] <seb_kuzminsky> dgarr: with HALPATH the user would copy & modify the .hal file from the system hal lib dir to their ini dir, and not have to modify the ini file
[14:22:45] <dgarr> and then he has to explain all that or a helper has to devine that when something is wrong instead of saying try using the exact line HALFILE=LIB:filename
[14:23:37] <dgarr> again i just don't see enough reason to make an introductory version complicated, making a search path later is certainly doable if there is a user demand
[14:24:17] <seb_kuzminsky> ok
[14:25:44] <seb_kuzminsky> alright, i think that's all the feedback i have
[14:26:01] <seb_kuzminsky> i accept your opinion that an explicit LIB: is simpler to support with our userbase
[14:27:30] <dgarr> i think i am about done with the files that are priority to me. I've done it rebased on master but life would much simpler if it could be accepted for 2.7 most things are noninterering except the detection of the keyword in linuxcnc.in
[14:28:06] <dgarr> future work if folks want it to address the Makefile copy_configs stuff would not be appropriate for 2.7
[14:34:08] <seb_kuzminsky> yeah, cool, push it to 2.7
[14:34:12] <seb_kuzminsky> it's early days yet
[14:35:10] <dgarr> ok -- i will wait a few days in case others want to chime in first
[14:36:09] <seb_kuzminsky> sure
[14:36:26] <seb_kuzminsky> i'm going to try to make a 2.7.0~pre3 soon
[14:36:41] <seb_kuzminsky> all the docs work was to prepare to put the release notes into the git docs instead of the wiki
[14:36:50] <seb_kuzminsky> i'll hold off until you push hallib to 2.7
[14:37:03] <pcw_home> Is there a null hall pin?
[14:37:26] <seb_kuzminsky> pcw_home: what do you mean?
[14:37:45] <seb_kuzminsky> dgarr: thanks for you work on this, it's a good improvement over the current situation
[14:38:22] <pcw_home> A no-op pin that allows any kind of assignment
[14:38:37] <kb8wmc> dgarr: I am having trouble with gcmc, it does not seem to want to install the executable...I d/l'd the tar file (gcmc-1.5.2) and unpacked it, ran the ./configure all seemed well up to this point but when I ran 'make' it went through the operation, but gcmc executable was not installed anywhere
[14:38:54] <seb_kuzminsky> a pin that you can connect to a net of any data type?
[14:39:03] <seb_kuzminsky> (bit, u32, float, etc)
[14:39:57] <pcw_home> more setp (trying to figure out how to share a common hal file with different hardware)
[14:40:50] <seb_kuzminsky> each hal pin has a definite data type, and can only accept setp and net-connections of that data type
[14:41:11] <seb_kuzminsky> there are comps that convert from one data type to another
[14:41:16] <seb_kuzminsky> and there are "tristate" comps
[14:41:33] <seb_kuzminsky> maybe a circuit could be build that does approximately what you want?
[14:41:58] <pcw_home> Its more a hal/ini syntax parser issue
[14:42:20] <dgarr> kb8wmc: i havent looked at gcmc recently, when i did i built from git, i don't know if there is an 'install' process with the tar file, you may just need to get the executable in your PATH
[14:43:17] <seb_kuzminsky> pcw_home: i must not understand what you
[14:43:21] <seb_kuzminsky> you're trying to do
[14:44:33] <kb8wmc> dgarr: thanks for info....I guess I am lost on the proper path as I have followed what I thought was all instructions relating to proper path
[14:44:43] <pcw_home> for example, i'm pretty sure i can make a common hal file for 5I20/7I33 and 7I77 with the appropriate aliases in the ini file
[14:44:45] <pcw_home> except the hals file for the 7I77 needs some additional parameter setup in the hal file
[14:44:46] <pcw_home> (I was hoping that parameter setup could become harmless no-ops with the right aliases)
[14:45:17] <pcw_home> (in the 5i20/7I33 case)
[14:45:45] <seb_kuzminsky> pcw_home: you might be able to use the tcl interface to hal to only call setp if the pins exist? lucky you dgarr's around, you can ask him :-)
[14:46:17] <kb8wmc> dgarr: I also tried to install the git tar, with same results
[14:46:53] <pcw_home> where's
[14:46:54] <pcw_home> if exist halpin {
[14:46:56] <pcw_home> :-)
[14:47:39] <dgarr> kb8wmc: i have : ls `which gcmc` /usr/local/bin/gcmc -> /home/git/gcmc/src/gcmc -- so i made a soft link to the executable in the git tree
[14:47:39] <dgarr>
[14:49:06] <seb_kuzminsky> altcl example that does that, i think:
http://www.linuxcnc.org/docs/2.6/html/hal/haltcl.html#_haltcl_examples
[14:49:23] <seb_kuzminsky> err, "here's a haltcl example that does that"
[14:50:00] <dgarr> beat me to it:if {[hal list pin axis.$axno.motor-pos-cmd] == {}} { continue }
[14:50:20] <seb_kuzminsky> that's pretty cool :-)
[14:51:11] <kb8wmc> dgarr: rgr....will give it a go....I sure don't know what I have been doing incorrectly....the instructions state that gcmc installs in "src", can't find it anywhere, I won't keep you any longer but would like to ask if I could further communicate with you should I not get this resolved
[14:51:37] <kb8wmc> dgarr: thank you for your time and input
[14:53:31] <dgarr> note that the list command is one of a few that needs special treatment as mentioned
http://www.mail-archive.com/emc-developers%40lists.sourceforge.net/msg02513.html
[14:53:52] <seb_kuzminsky> dgarr: and also i the great haltcl docs that i linked above
[14:54:06] <seb_kuzminsky> i hadn't read that document before but it's really clear
[14:54:30] <dgarr> thanks for jepler implementing it
[14:56:36] <pcw_home> ahh I'll have to look at haltcl that looks great
[14:57:03] <dgarr> kb8wmc: it looks like gcmc make puts the executable in src/ then i manually added the soft link, alternatiely one could edit there .profile or .bashrc or whatever and append the gcmc/src directory to the PATH variable
[14:58:04] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 0866e16 06linuxcnc 10docs/src/getting-started/Updating_LinuxCNC.txt 10docs/src/getting-started/Updating_LinuxCNC_es.txt 10docs/src/getting-started/Updating_LinuxCNC_fr.txt docs: remove instructions for upgrading 2.3 to 2.4 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0866e16
[14:58:14] <dgarr> the hal language is really like a simple subset of tcl syntax, you don't have to learn a lot of tcl to use hal commands
[14:58:24] <pcw_home> The PID run stepgen needs some calculated PID values and that could be done with haltcl also
[14:59:23] <kb8wmc> dgarr: rgr that, but what is the location of the proper src/ directory?
[15:00:57] <dgarr> kb8wmc: it can be anywhere if 1) the link is correct and 2) the link is in your PATH, 3) the file is executable. you can tell an executable is with the 'which' command
[15:04:18] <kb8wmc> dgarr: rgr that, I am trying to track it down, I already checked the /usr/local/bin but gcmc is not in there...
[15:05:58] <kb8wmc> dgarr: the 'which gcmc' comes back with no such file or directory
[15:07:03] <dgarr> yes, you have to create the link or modify the PATH, to make a link: sudo ln -s the_exact_path_to_the_gcmc_executable /usr/local/bin/
[15:11:34] <kb8wmc> dgarr: ok...just found that it build the /src directory within the unpacked directory gcmc...I may be able to work it through now....
[15:19:11] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 7bf2bba 06linuxcnc 10docs/src/getting-started/Getting_LinuxCNC.txt docs: add an intro blurb to Getting LinuxCNC * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7bf2bba
[15:19:11] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 6356407 06linuxcnc 10docs/src/getting-started/Updating_LinuxCNC.txt docs: add an intro blurb to "Updating LinuxCNC" * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6356407
[15:26:08] <dgarr> seb_kuzminsky: i looked at that error in axis on asynchronous code report but could not reproduce on any os i have (quantal,lucid, wheezy) so may need someone running jessie to find the problem -- it is certainly not obvious , it might help if the OP would report what versions of tcl tk are in use on jessie
[15:33:30] <jepler> tcl8.6:
[15:33:31] <jepler> Installed: 8.6.2+dfsg-1
[15:33:33] <jepler> -- debian jessie
[15:33:51] <jepler> I get the error too, but whatever's causing it seriously nonobvious
[16:12:22] <seb_kuzminsky> ubuntu trusty (14.04 lts) has tcl 8.6 too
[16:12:37] <seb_kuzminsky> not sure if it has the same issue, i'll test it later this afternoon
[16:14:30] <pcw_home> Im running trusty but not a virgin install
[16:28:35] <pcw_home> looks like trusty uses 8.6.1
[18:29:35] <seb_kuzminsky> cradek: can you make a new wheezy live+install hybrid image with the 2.7~pre package & apt source?
[20:10:15] <jfigie_> Just out of curiosity. What would be required to get linuxcnc to send position data over Ethernet using Ethernet/IP?
[20:11:40] <Tom_itx> if i'm not mistaken that's being worked on
[20:11:49] <Tom_itx> with an ethernet mesa board
[20:13:19] <jfigie_> I know that basically that UDP messages would be sent at the 1mSec rate from linuxcnc and also position updated and other info would be received at the same rate
[20:13:55] <jfigie_> from the drives
[20:16:25] <micges> jfigie_: what do you trying to do?
[20:17:28] <jfigie_> OK I want to understand how difficult it would be to get linuxcnc to talk to things like Rockwell Automation Drives that use CIP motion
[20:17:42] <jfigie_> CIP motion is over ethernet
[20:18:04] <micges> jfigie_: link?
[20:18:27] <jfigie_> yes
[20:19:29] <micges> jfigie_: sorry :) , could you paste link for example drive or documantation?
[20:19:48] <jfigie_> I know that first IEEE-1588 PTP would need to be implemented.
[20:21:01] <jfigie_> Well that is the difficult part, pasting the drive info. Ethernet/IP an CIP are "open" standards but to get them you must purchase through ODVA and the cost is high $1000
[20:21:28] <mozmck> heh, that's not exactly "open" :)
[20:21:30] <jfigie_> but I have access to the information.
[20:21:45] <jfigie_> I agree
[20:23:02] <jfigie_> But I know that in each control cycle the motion controller sends UDP messages to each of the drives and then each drive replies with a UDP message in the same cycle
[20:23:03] <micges> jfigie_: you can base on hm2_eth driver, it's just transition layer in linuxcnc, you can add any protocol on top of this
[20:23:43] <micges> and you can run it up to 4kHz on fast pc with a lot of cache
[20:23:55] <micges> transmition*
[20:25:01] <jfigie_> Dosen't linuxcnc typically use 1 msec for the servo update rate?
[20:25:12] <micges> yes
[20:25:21] <jfigie_> so then 1 KHz is all that is needed
[20:25:29] <micges> hm2_eth driver supports only one eth board atm
[20:25:57] <jfigie_> So this is a Mesa board?
[20:26:19] <micges> I don't know yet how it will behave with multi boards
[20:27:05] <jfigie_> Each drive has an ethernet swicth so it is easy to hook them in a linear network
[20:27:24] <jfigie_> 2 RJ-45 ports on each drive
[20:28:39] <micges> that's better but still
[20:30:15] <micges> we use normal ethernet sockets in realtime hardened kernel, for such setup I think rt-net smust be used but it's quite hard to use it
[20:30:47] <micges> rt-net has realtime tcp/ip stack
[20:31:57] <jfigie_> yes that is the part I was wondering about. To make it realtime
[20:34:26] <jfigie_> So I think someone has or is working on ehterCAT. I think that would be similar in some ways for linuxcnc.
[20:34:47] <jfigie_> *etherCAT
[20:42:49] <jfigie_> OK I did a search and found a reply from Jepler - looks like Mesa's 7i80 cards communicate using hm2_eth driver like you say.
[20:43:46] <jfigie_> The next hurdle would be how to get the IEEE-1588 PTP to work.