First, Matt, thanks for your responses. Matt, is this the version you are running? # ethercat version IgH EtherCAT master 1.5.1 35223d2e6e72
So, Matt's solution didn't work for me. I took out the callbacks from my program and ran it. The network went into operation. Then I did: # ifconfig eoe0s7 up # ifconfig eoe0s7 192.168.127.10 That brought the interface up and gave it the IP Address 192.168.127.10 successfully. I pinged that interface, and got a response. Then, I tried to ping 192.168.127.254, which is the device that it's attached to. # ping 192.168.127.254 PING 192.168.127.254 (192.168.127.254) 56(84) bytes of data. >From 192.168.127.10 icmp_seq=1 Destination Host Unreachable The error log is going crazy with these messages. I think it must be the problem: [ 2687.384659] [ 2687.384665] Pid: 0, comm: swapper Tainted: P W (2.6.32-42-generic-pae #95-Ubuntu) Latitude E6510 [ 2687.384672] EIP: 0060:[<c03ac336>] EFLAGS: 00000202 CPU: 3 [ 2687.384680] EIP is at acpi_idle_enter_bm+0x275/0x2a4 [ 2687.384684] EAX: c088eb4c EBX: 00000ee7 ECX: 00000000 EDX: 03036000 [ 2687.384689] ESI: 00000000 EDI: f6e404cc EBP: f74cbf78 ESP: f74cbf50 [ 2687.384694] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 2687.384698] CR0: 8005003b CR2: b94c0004 CR3: 00799000 CR4: 000006f0 [ 2687.384703] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 [ 2687.384707] DR6: ffff0ff0 DR7: 00000400 [ 2687.384710] Call Trace: [ 2687.384719] [<c04ca54a>] cpuidle_idle_call+0x7a/0x100 [ 2687.384727] [<c01085a4>] cpu_idle+0x94/0xd0 [ 2687.384735] [<c05b31b7>] start_secondary+0xc4/0xc6 [ 2687.393250] BUG: scheduling while atomic: swapper/0/0x10000100 [ 2687.393256] Modules linked in: durability ec_generic ec_e1000 ec_8139too ec_master mii michael_mic arc4 binfmt_misc snd_hda_codec_idt snd_hda_intel snd_pcm_oss snd_hda_codec snd_hwdep snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event pcmcia dell_wmi snd_seq fbcon tileblit font snd_timer uvcvideo nvidia(P) sdhci_pci yenta_socket rsrc_nonstatic bitblit psmouse dell_laptop sdhci videodev agpgart v4l1_compat ppdev snd_seq_device softcursor pcmcia_core lib80211_crypt_tkip snd led_class dcdbas serio_raw soundcore snd_page_alloc vga16fb vgastate wl(P) lib80211 parport_pc video output lp parport ses enclosure usbhid usb_storage hid ohci1394 ahci ieee1394 e1000e [last unloaded: e1000] These messages only appear when I activate the EoE interface. Please note that I am not doing any locking in my program at this time. Thanks in advance for any help. Thanks! Tom On Wed, Aug 15, 2012 at 10:26 AM, Matthieu Bec <m...@gmto.org> wrote: > note that's using the master stack only. > > I don't use the EtherLAB suite. There could be an issue if it requests the > master and its internal loop doesn't "send_ext". Actually > ecrt_master_send_ext isn't exported by cdev so that could indeed be a > problem. > Can you try starting the master only? > > On 08/15/12 07:48, Matthieu Bec wrote: > >> I have an EL6614, besides starting the master (stable-1.5), configuring >> the network interface and bringing it up, nothing else is needed to get >> EOE connectivity. >> >> >> On 08/14/12 15:15, Thomas Bitsky, Jr. wrote: >> >>> Ok, so I made some progress, I think. I was able to build as a kernel >>> module and install the module. So long as the virtual interface (eoe0s7) >>> is not up, the program brings the network into Operation and scans at >>> 100Hz. >>> >>> Then, I issue # ifconfig eoe0s7 up >>> >>> About 20 seconds later, the entire system hangs and I need to reboot. >>> >>> In the kernel log, I am seeing this: BUG: scheduling while atomic: >>> swapper/0/0x10000100 >>> >>> My understanding is that occurred when using semaphores when spinlocks >>> should have been used in the master callbacks. I changed over the >>> program to spin locks, but the same thing occurred. >>> >>> I'm not sure what I could try other than falling back to 1.4.0 and >>> seeing if I'm just running into a stable-1.5 bug. I'm following the tty >>> examples in the directory very closely. Beyond changing the hardware >>> declarations to match the network, it's the same program. >>> >>> Does anyone have an EoE example they could share? >>> >>> Thanks! >>> T >>> >>> >>> On Tue, Aug 14, 2012 at 7:29 AM, Matthieu Bec <m...@gmto.org >>> <mailto:m...@gmto.org>> wrote: >>> >>> >>> Hello Thomas, >>> >>> it might be a simple network config problem: the IP address of your >>> virtual interface shouldn't be the same as your field device. Try >>> assigning it something different on the same subnet, e.g. >>> 192.168.127.1/8 <http://192.168.127.1/8> and check your routing >>> table is correct >>> >>> Regards >>> >>> On 08/13/12 22:21, Thomas Bitsky, Jr. wrote: >>> >>> Hello! I'm new to using EtherLAB. I've got the master >>> installed as a >>> service, and it's communicating to the network fine. However, >>> I'm having >>> trouble getting the EoE feature up and running. >>> >>> I have an Ethernet device in the field with the IP Address >>> 192.168.127.254 that I need to communicate with through a web >>> browser. I >>> have an EL6601 that the master is able to see fine. When I put >>> the >>> network into Operation, the RUN light goes steady. >>> >>> I'm running on Ubuntu 10.04. I have not installed any real-time >>> extensions; I'm just working with EtherLAB right now. >>> >>> If I execute: >>> # ethercat eoe >>> >>> I get a listing for eoe0s7 as a virtual interface, and that it >>> is down. >>> >>> >>> So, I created in /etc/network the file ifcg-eoe0s7 with the >>> following >>> contents: >>> >>> IPADDRESS=192.168.127.254/8 <http://192.168.127.254/8> >>> <http://192.168.127.254/8> >>> STARTMODE=auto >>> >>> I restarted the computer. >>> >>> To raise the interface, I enter: >>> >>> # ifconfig eoe0s7 up >>> >>> The virtual interface goes up, and the LINK light on the >>> EL6601 goes >>> solid green. >>> >>> However, I'm unable to ping 192.168.127.254, or get the pages it >>> serves >>> to pop up. So, I did more reading, and I think I need to do some >>> function calls in the program. So, I added to my test program: >>> >>> >>> void send_callback(void *cb_data) >>> { >>> ec_master_t *m = (ec_master_t *) cb_data; >>> sem_wait(&mutex); >>> ecrt_master_send_ext(m); >>> sem_post(&mutex); >>> } >>> >>> >>> /*******************************__****************************** >>> **__******************/ >>> >>> >>> void receive_callback(void *cb_data) >>> { >>> ec_master_t *m = (ec_master_t *) cb_data; >>> sem_wait(&mutex); >>> ecrt_master_receive(m); >>> sem_post(&mutex); >>> } >>> >>> int >>> main(int argc, char **argv) >>> { >>> >>> ... >>> >>> // setup callbacks for EoE >>> ecrt_master_callbacks(master, send_callback, >>> receive_callback, master); >>> >>> ... >>> >>> } >>> >>> >>> >>> However, it won't build: >>> >>> durability.o: In function `send_callback': >>> /home/tbj/srcroot/durability/_**_src/durability.c:279: undefined >>> reference >>> to `ecrt_master_send_ext' >>> durability.o: In function `main': >>> /home/tbj/srcroot/durability/_**_src/durability.c:321: undefined >>> reference >>> to `ecrt_master_callbacks' >>> >>> >>> This is my makefile: >>> >>> CC = gcc >>> ETHERCAT_TOPDIR = /home/tbj/srcroot/ethercat >>> CFLAGS = -I$(ETHERCAT_TOPDIR)/include -g -O2 >>> LDFLAGS = -L$(ETHERCAT_TOPDIR)/lib/.libs -lethercat -lrt >>> >>> OBJECTS = durability.o >>> >>> durability.exe : $(OBJECTS) >>> $(CC) $(CFLAGS) $(OBJECTS) $(LDFLAGS) -o durability.exe >>> >>> %.o : %.c >>> $(CC) $(CFLAGS) -c $< >>> >>> >>> Can anyone tell me what I'm missing? I feel like I'm one step >>> away from >>> having this working, but I can't find anything else in any >>> documentation >>> that would lead me to the answer. >>> >>> Thanks in advance for any help. >>> >>> T >>> >>> >>> ______________________________**___________________ >>> etherlab-users mailing list >>> etherlab-users@etherlab.org <mailto:etherlab-users@** >>> etherlab.org <etherlab-users@etherlab.org>> >>> http://lists.etherlab.org/__**mailman/listinfo/etherlab-__** >>> users <http://lists.etherlab.org/__mailman/listinfo/etherlab-__users> >>> >>> <http://lists.etherlab.org/**mailman/listinfo/etherlab-**users<http://lists.etherlab.org/mailman/listinfo/etherlab-users> >>> > >>> >>> >>> >>> -- >>> Matthieu Bec GMTO Corp. >>> cell: +1 626 354 9367 <tel:%2B1%20626%20354%209367> P.O. Box >>> 90933 >>> phone: +1 626 204 0527 <tel:%2B1%20626%20204%200527> Pasadena, >>> CA 91109-0933 >>> >>> >>> >>> >>> -- >>> Thomas C. Bitsky Jr. >>> Lead Developer and Application Engineer >>> ADC | automateddesign.com <http://automateddesign.com> >>> P: 630-783-1150 F: 630-783-1159 M: 630-632-6679 >>> >>> ______________________________**_________________ >> etherlab-users mailing list >> etherlab-users@etherlab.org >> http://lists.etherlab.org/**mailman/listinfo/etherlab-**users<http://lists.etherlab.org/mailman/listinfo/etherlab-users> >> > > > -- > Matthieu Bec GMTO Corp. > cell: +1 626 354 9367 P.O. Box 90933 > phone: +1 626 204 0527 Pasadena, CA 91109-0933 > > -- Thomas C. Bitsky Jr. Lead Developer and Application Engineer ADC | automateddesign.com P: 630-783-1150 F: 630-783-1159 M: 630-632-6679
_______________________________________________ etherlab-users mailing list etherlab-users@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-users
