hbausley

The linux headers are supplied with the IDE. They are located C:\DeltaTau\PoewrPMAC\Compilers\opt\powerpc-405-rootfs\usr\src\linux-2.6.30.3-xenomai-2.5.6. these are the headers the IDE compiles with to build kernel modules for usralgos.

1.) Make your disk writable mount -o remount,rw / 2.) Next you must update the repository list file. Debian lenny is used on a 460 CPU so you must change the repositories to archive.debian.org. deb http://archive.debian.org/debian/ lenny main non-free contrib deb-src http://archive.debian.org/debian/ lenny main non-free contrib deb http://archive.debian.org/debian-security/ lenny/updates main non-free contrib deb-src http://archive.debian.org/debian-security/ lenny/updates main non-free contrib The sources.list file placed in /etc/apt should look like what is above 3.) next issue the apt-get update command to reload the repositories. You can disregard the KEYEXPIRED warning message that comes back 4.) next issue the apt-get install lighttpd command to install lighttpd lighttpd is now installed. 5.) Make sure the modifications from the apt-get install command make it to the readonly etc folder. Do this by issuing the following command cp -a /.readonly/etc-tmpfs-mirror/* /.readonly/etc/ 6.) Put the disk back to readonly mode mount -o remount,ro /

We send the units with software licence files in the C:\DeltaTau\MotionCore\opt\etherlab\etc\sysconfig folder. Disregard the dongle as It has been determined by Product Marketing we will use software licensing only for now on.

The Com ports UART based. The LX86 (Linux GUI version uses Xenomai ) so they are available. The WX86 (Windows GUI occupies CPU 1,2). Linux PREEMPT RT resides on CPU 3,4. The COM Ports can be moved to the CPU's running the hidden linux RTOS running in CPU 2,3 by editing a text file. For the LX86 modbus can be placed on any of the Ethernet ports. For the WX86 modbus can be placed upon the the extra dedicated Ethernet port. Two Ethernet ports are allocated to Windows and two are allocated to Linux. One of the two for Linux is always pre-configured for EtherCAT. The other is not configured, it can be setup for EtherCAT or standard ethernet. For the LX86 the host operating system is not mounted readonly. This is a good idea so we will patch the union file system driver to the xenomai enabled kernel we compiled so with a script this that feature can be enabled in the near future. I suspect there will be many who want to use an LX86 headless instead of an EtherCAT ultralite. So your thought is a good one. For the WX86 the linux portion is readonly. In fact it runs its filesystem in RAM. The only connection to disk is through an NFS share to the Windows host. The usrflash is saved via NFS to the Windows disk. Windows should be shutdown using our tray icon application so it turns off all 4 cpu's. We have not tested with the Windows Enhanced Write Filter (EWF) this but I see no reason why it would be a problem. Communication for the WX86 it is done through a virtual Ethernet Connection. This allows applications already developed for our embedded PowerPMAC boards to function without modification. Currently you cannot get to the WX86's shared memory via Windows directly. Any normal backup utility should work with these systems. As far as pricing you have to contact customer service for that.

Do you have ecat[0].enable=1 saved? What is likely happening is on power up the ethercat configuration is not valid since the robot device isn't present for a minute or two. If a project is not valid a factory default state is set. Check via the powerpmac's ftp site ftp://192.168.0.200/usrflash/Project/Log for pp_error_hist.log this will verify how the loading failure occurred. You can so set Ecat[0].enable=0 so there is not a power up fault. Once your ethercat robot controllers are up you can set Ecat[0].enable=1 in your code. Perhaps you can use an ecatsdo to see if the robot controller is up.

Thank you for the detailed diagnostic. VendorID was suppose to stop the backup not Product Code.

You have to be careful with OMRON drives. I have had feedback that they get occasional B2 warnings with our controller? I'm not sure of the root cause of this since I obviously don't have their code to know what triggers the error. In addition, in cyclic torque mode you must make sure that the drive has a scale factor for the torque command in their drive. By DS402 specification the torque command is written in thousandths of rated motor torque which would lead to horrible resolution. Copley has a nice way of overcoming this with a scale factor in its drive. Check out their doc below http://copleycontrols.com/Motion/pdf/Current-Scaling.pdf

You can point the servo algo back to the built in servo Motor.Ctrl = Sys.ServoCtrl or deactivate the Motor[].ServoCtrl=0 If we were to call your user written servo when it was out of memory because it was being replaced with a newer version there would be a kernel mode crash resulting in a watchdog.

We have done this on demos using mono and it will work. You must be careful to insure that you do not directly call Windows API functions directly as this would break mono compatibility, you must go through the C# classes. However, from a practical standpoint a 1Ghz single core PC with a GUI is not very responsive. But also take into consideration that much of the duty cycle of the PowerPMAC is constantly being used for motion control, now that PC runs more like a 500MHz PC. Furthermore, take into consideration the video adapter is fundamentally a USB 2.0 Video adapter as there were no good PCI express video chipsets at the time that would work with a PowerPC at design time. In summary you will not get stellar performance. In addition, consider the additional cost of the PowerPMAC Video Adapter and memory and it may cost you more than a separate PC. We are looking into the possibility of using faster processors and video adapters in the future and at that time it may be more practical.

Yes. Since you don't have hardware interrupts with an axis card you must use the cpu's built in timer interrupt. In this case the cpu, power supply and ethernet card are all that is required. Therefore, Sys.ServoPeriod to the desired period usually 1000msec or 500msec and Sys.CPUTimerIntr=1 then save and power cycle. You must order the EtherCAT option when ordering the CPU so that you get the EtherCAT compatible network card. I assume you have done this. Also there is the Power PMAC Etherlite product http://www.deltatau.com/DT_Products/ProductDetailDescription.aspx?CatID=P10-POWER%20PMAC%20ETHERLITE

I suspect the file /opt/etherlab/etc/sysconfig/ethercat Is being overwritten by the backup. This file contains the MAC address of the ethernet card used for ethercat. Issue the command system ethercat master The results will look as follows. If the line that contain Main: says has (waiting...) the file was overwritten and that is the problem. If it has (attached) then it is o.k. and the problem is elsewhere. system ethercat master Master0 Phase: Idle Active: no Slaves: 6 Ethernet devices: Main: 00:50:c2:12:c1:97 (attached) Link: UP

You cannot use pmac variables with the system command. The system command forwards a string to be operated on by the operating system. Of course, ecatsdo command works fine. But I couldn't fix sdo problem yet... so I must use system ethercat command. How can I PPMAC variables with system commands?? Please let me know Thanks.

When it happens again take a look at the log files in ftp://192.168.0.200/usrflash/Project/Log and the ftp://10.34.9.238/usrflash/Temp maybe that will give us a clue as to what is going on.

If errors arise when building a project in the IDE related to vfork or fork the problem is usually caused by an offending application. See the links below http://cygwin.com/faq/faq-nochunks.html#faq.using.fixing-fork-failures http://cygwin.com/faq/faq-nochunks.html#faq.using.bloda When this problem arises errors similar to what is below typically show up. powerpc-405-linux-gnu-g++: vfork: Resource temporarily unavailable [main] powerpc-405-linux-gnu-g++ 7616 fork: child -1 - died waiting for longjmp before initialization, retry 0, exit

I believe this is an omission of error checking in the sample slave code. In the slave code firmware you can check to make sure that you are receiving the correct number of bytes and if you do not return an error. This is how almost all the slaves we have tested seem to work. -m0 is for the master number. If you have a ethercat master card with two ports you need to specify -m0 or -m1 to indicate which master to use. If you have an ethercat master card with a single port you may omit the -m0 To write to the second slave use the -p parameter. -p0 is the first slave, -p1 the second slave, -p2 the third etc. issue the command system ethercat -- help and you will see all of the possible parameters The new command being considered could appear in the next release of the firmware release which we do not yet have scheduled but I can only guess will be in Q4 of this year. In the mean time you can use the system command to work around the issue or modify the slave firmware.

How are you setting 0x607D? Are you using an ecatsdo command? P0=ecatsdo(0,0,$607D,0,$4444,0) If so try the native command system ethercat -m0 -p0 -t int16 download 0x607D 0 0x4444 then read back system ethercat -m0 -p0 -t int16 upload 0x607D 0 If you find the native linux command works I suspect it is because if the incorrect length is requested an error is not being returned by your device. Our ecatsdo attempts the ethercat command above and if no error is returned it returns. It first attempts an 8 bit write, then a 16 bit, then 32 bit write. I think ecatsdo may be doing an 8 bit write and gets no error and returns. I have found most devices obey this. We will consider adding a new command ecatsdotype(0,0,$607D,0,$4444,0,bitlength) that forces you to specify the bit length for future firmware updates.

Can you make sure you don't have multiple copies of your app on the system. Maybe you are running a copy of your app that was built for the last version of firmware. You can check with the command system find / -name NameofYourApp.out Also the .h files that you should be compiling with are on the powerpmac ftp site. ftp://192.168.0.200/libppmac These are automatically uploaded to C:\Program Files\Delta Tau Data Systems, Inc.\2.0\Power PMAC Suite\powerpc-460-linux-gnu\usr\local\dtlibs by the IDE. If for some reason they are different that could be your problem. OK - for this issue, I don't care about piom memory, I only care about shared memory. As I said in my initial forum post, my C program, the IDE terminal, and the IDE motor status window don't agree on what's in the motor structures in shared memory. The IDE motor status window shows motor '1' has "Amp Enabled", the IDE terminal interface to the PowerPMAC shows: Motor[1].AmpEna = 1 however when my C program uses shared memory: if(pSHM->Motor[1].AmpEna) it DOES NOT show that the Amp Enabled bit is true. How do I determine why the C program doesn't correctly reference the correct bit? If I could determine the offset in shared memory the terminal interface uses for 'Motor[1].AmpEna , I could compare this to the offset my C program is using in shared memory. Again - this program used to work, and I've recompiled the program for the new libraries and IDE.

[quote='KEJR' pid='4728' dateline='1363975327'] I did get the USB serial port working and am using it on a machine in production. I think at the time I ended up talking to someone at Delta Tau and ultimately Henry Bausley built a special kernel for me that included the common USB-RS232 drivers into the kernel. I would think that by now the latest kernel would have this by default. I like the FTDI based USB-232 converters but at the time I bought a TrendNet TU-S9 adapter which uses one of the prolific chips and have not had any issues. I can certainly post some code. It took me a little time to piece it together into something that would be a nice library function. I can't guarantee its perfect, but it worked for me. I have a function to open a serial port connection, and another to read in a terminated line (with timeout). I use the readline function alot for industrial devices since it is common to write a command to the serial port and then wait for a response from a device. As far as the RTOS part of it, I didn't have any speed issues or any surprises in my application. It just worked surprisingly well. Frankly I wouldn't advise trying to do anything that needed to be deterministic with the serial ports. Charles: I'm going to send you an email off list to talk about the code I have and what to do with it. KEJR [/quote] RS232 support is indeed incorporated in the kernel that ships with the latest release firmware. If you want to see what options the kernel is compiled with issue this command from the IDE terminal system gzip -d --stdout /proc/config.gz Part of the output will be: CONFIG_USB_SERIAL=y CONFIG_USB_SERIAL_CONSOLE=y # CONFIG_USB_EZUSB is not set CONFIG_USB_SERIAL_GENERIC=y # CONFIG_USB_SERIAL_AIRCABLE is not set # CONFIG_USB_SERIAL_ARK3116 is not set CONFIG_USB_SERIAL_BELKIN=y # CONFIG_USB_SERIAL_CH341 is not set . . . # CONFIG_USB_SERIAL_NAVMAN is not set CONFIG_USB_SERIAL_PL2303=y

The powerpmac uses Xenomai. When you make standard linux system calls the thread you are making your call from switches from what is called primary mode to secondary mode and therefore is subject to sharing its time with regular linux processes such as ssh gpascii etc. Primary modes are scheduled by the Xenomai kernel, and benefits from hard real-time scheduling latencies, in secondary mode it is an ordinary Linux thread. http://www.xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai http://www.xenomai.org/documentation/trunk/html/api/group__posix__mq.html

Can you rephrase this? It is not clear to me what you want to do. An example would help us answer this.

I didn't put the full path for the inittab since I tested this from the etc directory. You should probable change inittab to /etc/inittab. Also there is no way to get rid of the initial data that comes out the serial port. Some of it is from the bootloader so if the device cannot handle useless information you will have to use a USB to RS232 converter. sed -i 's/T0:23/#T0:23/g' /etc/inittab

The powerpmac has /dev/ttyS0 tied to a linux console but you can turn it off with the following. Comment the line in /etc/inittab line that has ttyS0 This command will do it sed -i 's/T0:23/#T0:23/g' inittab Now kill the linux init process so it doesn't come back with the following command init q Go here http://papers.mpastell.com/serial.pdf and learn how to use the serial port over the linux console and you can do the following in a PLC open plc 1 if(p1==1) system"`echo Hello There >/dev/ttyS0`" p1=0 close Alternatively you can use a USB to RS232 converter in that case change /dev/ttyUSB0

Make sure you have setup distributed clocks set through the IDE. I assume you are using csp mode. Make sure that you have set your servo rate at one the amplifiers all can operate at ie. 1Khz or 2 Khz.

Please use the IDE as Atul suggested. However, to directly answer your question the the PDO's displayed are the defaults that are programmed into the device. Some vendors will place PDO info in their device by default and others will not. If they do not you must use the setup program and load the vendors XML file. The IDE will use the vendor XML file and load the PDO information.