Back
[07:49:49] <jepler> pcw_home: 7i80 doesn't respond on broadcast address?
[08:08:59] <pcw_home> Yes it has to for ARP
[08:12:45] <pcw_home> but all broadcast packets except ARP who-has are ignored
[08:23:15] <pcw_home> I guess it could respond to broadcast UDP as a simple way of finding the card
[10:08:42] <jepler> pcw_home: before I knew it didn't respond to broadcast UDP packets, I was thinking that broadcasting a request like 85491000 and waiting for a response could work
[10:14:35] <pcw_home> it would be trivial to add broadcast UDP response
[10:15:39] <pcw_home> at least I think it would
[10:19:40] <pcw_home> Just change this to accept 255.255.255.255
[10:19:42] <pcw_home> parseip
[10:19:43] <pcw_home> lda myip+0 ; You talkin to me?
[10:19:45] <pcw_home> sub @y,IPDestIPOff+0
[10:19:47] <pcw_home> jmpnz mainloop ; not for me
[10:19:48] <pcw_home> lda myip+1
[10:19:50] <pcw_home> sub @y,IPDestIPOff+1
[10:19:51] <pcw_home> jmpnz mainloop ; not for me
[10:19:53] <pcw_home> though this is for ICMP also not sure if I shoud include that
[11:01:15] <jepler> what ICMPs does it respond to besides echo (ping)?
[11:03:25] <pcw_home> just ping
[11:17:14] <jepler> here's my little program for probing ethernet boards, except that you actually have to hard-code the address so it's not too useful:
http://pastie.org/10103524
[11:18:53] <jepler> requries root, unfortunately, for SO_BINDTODEVICE
[11:20:30] <jepler> sending to the network's broadcast address (e.g., 10.255.255.255 or 192.168.1.255) doesn't require root but then the hostmot2 card has to know its netmask which is a new requirement
[11:23:29] <jepler> *another* new requirement
[11:23:39] <pcw_home> Yeah didnt think about that
[11:25:53] <pcw_home> not bad if the class is fixed to say 24/8 but I guess it could be a new EEPROM variable
[11:36:19] <jepler> mdns probably deserves consideration too
[11:37:02] <jepler> it might be better than my UDP broadcast idea
[11:38:54] <pcw_home> Yeah mdns seems cleaner
[11:39:42] <jepler> anyway not sure if you saw branch jepler/hm2-eth-simplify but it does get rid of several of those setup steps (sysctl and iptables)
[11:39:52] <pcw_home> it _looks_ fairly simple and I can just use the EEPROM card name for the time being
[11:40:20] <pcw_home> Yes I saw that thats great because those are all pretty tricky for users
[11:42:57] <jepler> even if you add mdns to the firmware, debian's /etc/network/interfaces has to match the card's configuration
[11:44:57] <jepler> for network address & mask
[11:54:44] <pcw_home> yeah
[12:03:57] <jepler> hm are there no 7i80 sample configs
[12:05:24] <jepler> and due to the need to specify ip= outside of config= I'm not sure it fits the mold sufficently either
[12:06:48] <jepler> I never run linuxcnc, just hal :-/
[15:28:30] <jepler> this is interesting: with SO_BINDTODEVICE, I can communicate with the 7i80 even if the interface in question has an "incompatible" address
[15:29:09] <jepler> e.g., if Linux has eth1 as 192.168.2.1 netmask 129.168.2.255, I can SO_BINDTODEVICE eth1 and sendto / recvfrom 192.168.1.121
[15:34:37] <jepler> hm then I did something that seems to have wedged the machine
[15:34:46] <jepler> $ sudo /sbin/ifconfig eth1 up inet 192.168.2.2 pointopoint 192.168.1.121
[15:38:37] <jepler> anyway, potentially hm2_eth could pick any unused subnet and then send packets to the 7i80 at 192.168.1.121 regardless of whether the subnets match
[15:38:49] <jepler> but only if calling ifconfig doesn't randomly hose the whole system
[15:44:58] <andypugh> I hope somone else can give an informed comment, that’s all Greek to me :-)
[15:46:21] <andypugh> Is there a _neat_ way for a HAL component to cause axis motion? That seems like a missing link from tool-changer implementations.
[15:47:21] <andypugh> The option to re-map M6 to a G-code subroutine makes it possible to do it all in G-code, but conversely G-code is clumsy for state machines and error trapping.
[15:47:42] <andypugh> And CL seems to have the same problems as a HAL component.
[15:49:05] <andypugh> I suppose the other option is a user-space Python component that can send MDI commands and also have HAL pins to connect to sensors. But user-space seems like an odd place to do that sort of thing.
[15:50:36] <andypugh> I don’t think you would be wanting to drive a carousel motor and wait for the right position in Python, as an example.
[15:57:20] <mozmck> PCW: do you have any 7i92 with 2 IDC connectors yet?
[16:05:40] <jepler> andypugh: remap is supposed to be able to call into Python
[16:05:57] <jepler> and then Python can turn around and issue motion that goes into the normal queue, I think
[16:07:45] <andypugh> Yes, it can (looking at the docs). It just seems an unnatural place to coordinate machine moves from. Maybe I need to re-think my opinions.
[16:08:35] <PCW> mozmck: we have PCBs (also for 7I92M) but have none built yet
[16:35:14] <andypugh> jepler: I just realised, I think that the fresh motion queue for Python is only for remap. And a remap routine can’t create HAL pins (well, it can but they probably won’t be there at HAL load time).
[16:36:18] <andypugh> I guess the remap Python could probably import the HAL python component and call routines in there though.
[16:36:29] <andypugh> I might experiment.
[16:36:32] <cmorley> Andy: remap can make and use hal pins
[16:37:26] <andypugh> Any examples?
[16:50:07] <cmorley> I have one i used for wear offsets... ill see if I can find it....
[16:57:08] <cmorley> andypugh:
http://pastebin.com/94BvMmDe
[16:57:29] <cmorley> then in toplevel.py:
[16:57:39] <cmorley> import remap
[16:57:40] <cmorley> def __init__(self):
[16:57:40] <cmorley> remap.init_pins(self)
[16:59:46] <andypugh> Aha! You can call the init code in toplevel.py?
[17:00:09] <cmorley> that was the trick yes
[17:00:20] <andypugh> That solves the problem that I couldn’t see the solution to.
[17:00:26] <cmorley> :)
[17:01:14] <andypugh> what does the REMAP line look like?
[17:01:35] <cmorley> in INI u mean?
[17:02:10] <andypugh> Yes. Normally it seems to point to an executable file, and it starts at the beginning…
[17:02:17] <cmorley> REMAP = T python=index_fanuc_lathe_tool
[17:02:34] <cmorley> plus this:
[17:02:38] <cmorley> [PYTHON]
[17:02:38] <cmorley> # where to find Python code
[17:02:38] <cmorley> # code specific for this configuration
[17:02:38] <cmorley> PATH_PREPEND=./
[17:02:38] <cmorley> # generic support code
[17:02:38] <cmorley> PATH_APPEND=../../nc_files/remap_lib/python-stdglue/
[17:02:38] <cmorley> # import the following Python module
[17:02:39] <cmorley> TOPLEVEL=toplevel.py
[17:02:39] <cmorley> # the higher the more verbose tracing of the Python plugin
[17:02:40] <cmorley> LOG_LEVEL = 0
[17:02:59] <andypugh> Ah, because the toplevel imports the file, which means the def-ed functions are available.
[17:03:31] <andypugh> Clever bit of coding that remap faciltity.
[17:04:33] <cmorley> well You can't say Michael H was a dummy :)
[17:05:30] <cmorley> What are you doing with remap?
[17:07:02] <andypugh> I am not doing anything other than trying to answer forum questions :-)
[17:07:32] <andypugh> (Or, rather, forum questions set me wondering “how can we do that neatly?"
[17:07:36] <cmorley> You are a good man charlie brown !
[17:08:08] <cmorley> Ya that often is what does it for me ... the puzzle intrigues me
[17:09:19] <cmorley> Someone asked for wear offset solution a little different from your sample so I played till I got it to work
[17:11:40] <cmorley> I toyed with the though of trying to add axes movement to classicladder...then thought better of it
[17:27:30] <jepler> > Apr 19 14:14:19 rat kernel: [32077.804073] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
[17:27:38] <jepler> no, that was yesterday
[17:27:58] <jepler> Apr 20 06:23:55 rat kernel: [13325.804080] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
[17:28:03] <jepler> hm apparently this happens a lot
[17:28:29] <jepler> no messages logged from the hang this afternoon :-/
[17:30:17] <andypugh> I got an annoying compiler error today. Not with LinuxCNC, but with the Arduino compiler. “confused by earlier errors, bailing out”
[17:31:09] <andypugh> (The real problem is earlier: “ error: unable to find a register to spill in class 'POINTER_REGS’” ) which I don’t think is anything to do with my actual code.
[17:33:02] <jepler> I forget just what I wrote, but it made gcc print an apology that they hadn't gotten around to implementing some C++ feature yet
[17:33:50] <andypugh> Well, at least they were honest.
[17:34:04] <jepler> s'pose so
[17:34:14] <andypugh> My error message doesn’t give me any clue at all what s wrong, or how to get around it.
[17:35:11] <andypugh> The truly wierd thing is that the code worked, then I added another (overloaded) function, and it stopped working, so I deleted the extra function, and it continued to not work.
[17:36:24] <andypugh> I have been told it is a compiler bug. But no clue how to not trigger it.
[17:37:03] <jepler> ugh, there are spammers who target public bugzillas -- seen at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18251#c42 when looking for clues about your compiler error
[17:37:54] <jepler> anyway my impression is that you are hitting a compiler bug, but arduino doesn't offer you a lot of latitude to try with different compiler flags or versions as far as I know
[17:39:17] <andypugh> Also a bug that looks to have been fixed 10 years ago?
[17:39:40] <jepler> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50925
[17:42:34] <andypugh> I wonder how I figure out the version of gcc that Arduino is using on Win 7?
[17:43:05] <andypugh> (this is actually a side-project at work)
[18:06:54] <andypugh> Goodnight chaps
[21:52:32] <jepler> I can do nutty things to make hm2_eth find and communicate with the board, but it doesn't help mesaflash
[21:53:12] <jepler> so I suppose I could propose similar nutty things for mesaflash. merely requiring root is no big deal, since it's required for other board types already
[21:57:09] <jepler> I feel a bit ill at ease at hm2_eth manipulating firewall rules as much as it does
[21:57:45] <jepler> the idea that hm2_eth and mesaflash would take an ethernet interface up/down puts me ill at ease
[22:13:57] <jepler> 96boards hikey remains MIA. the other announced board in that form factor still has no release date, though some sites are claiming the price will be set at $75.
http://www.fool.com/investing/general/2015/04/05/microsoft-corporation-gains-a-key-ally-in-the-inte.aspx still nobody has said how much RAM it will have.