hbausley

Try adding it to the interfaces network configuration file. Make you file look like auto eth0 iface eth0 inet static address 192.168.0.200 netmask 255.255.255.0 gateway 192.168.1.254 up route add -net 192.168.2.0 netmask 255.255.255.0 gw 192.168.0.200 [url]http://www.cyberciti.biz/tips/configuring-static-routes-in-debian-or-red-hat-linux-systems.html[/url] Let us know if it works. [quote='MClement' pid='3112' dateline='1328880578'] hbausley We need to add an IP Route to our device and I cannot seem to be able to save it. I can manually type it at the command prompt as follows ip route add 192.168.0.2 via 192.168.0.10 and I can confirm it took by typing "route" and viewing. I cannot figure out where it needs to get put so that on reboot it runs the command each time. I've tried adding it to the end of the /etc/interfaces file but that doesnt seem to work. Is there a script somewhere I need place this command? [/quote]

I am a little confused. I thought you wanted something running as a separate thread? Do you want to do both? If you want a function called by the phase interrupt use the built in useralgo. If you must start a thread in addition to having a routine started called by the ISR you can modify useralgomain.c and in the init_module you can launch your thread. If you want to start the thread from a user app create an ioctl as part of the kernel module in useralogmain.c If you look at the folder where useralgo is created you will see useralgomain.c is created by the IDE. However , there is an issue that the IDE overwrites useralgomain.c and the makefile every time you build and download so you would have to manually type make -f [project.mak] from a command line then copy the useralgo.ko to the PowerPMAC. If you wanted to do your own seperate kernel module and wanted a particular function callable by the phase routine. You would need to EXPORT_SYMBOL the function you wanted callable and Force the address of your function into UserAlgo.PhaseAddr[] with a c application. Once your kernel module is loaded ie. with a insmod yourdrv.ko you could do a cat /proc/kallsyms | grep your_function and you will see what the address of your function is. If your ambitions see the references book Linux Device Drivers by Corbet,Rubini and Kroah-Hartman for writing Linux Drivers

If you look in /.readonly/etc-tmpfs-mirror you will see what files were changed when you updated the route table. Can you tell us what you did to update the route table. So you will do a mount -o remount,rw / cp /.readonly/etc-tmpfs-mirror/[changed files] /.readonly/etc/[changed files] mount -o remount,ro /

You could try creating a thread from the useralgo the first time it runs and have the thread wait in a sleep but it might crash since it would be trying to create a thread from the context of an interrupt. You could also try creating the thread from a Cfromscript function see the link below it has a nice write up on using Cfromscript http://forums.deltatau.com/showthread.php?tid=669&highlight=Cfromscript You may have to resort to creating your own driver from scratch in that case you will have to compile from a command line prompt and learn how to make a linux driver from scratch.

That is not actually bad at all. Remember the ADCs are latched on the falling phase clock edge and the outputs transmitted on the next falling edge. So as you are not using 50% of the duty cycle you will be fine.

See this thread it explains that the filesystem is read only. http://forums.deltatau.com/showthread.php?tid=198&pid=447&mode=threaded If you look in /.readonly/etc-tmpfs-mirror you will see what files were changed when you updated the route table. Can you tell us what you did to update the route table. So you will do a mount -o remount,rw / cp /.readonly/etc-tmpfs-mirror/files cp /.readonly/etc/files mount -o remount,ro /

Try placing them on totally different networks. Set eth1 on its own private network ie. 192.168.0.x and leaving eth0 on 172.16.150.x

The additional ack parameter if set to 1 returns a character 6 to indicate the end of a multiple line response. GetResponseEx will handle the following additional commands, save,$$$,$$$***,reboot, and macro station close. It will also handle symbolic names provided a project with symbols has already been loaded.

A crossover cable is never necessary with a PowerPMAC. You can place the Modbus WAGO unit on the same network as the Power PMAC and IDE. Or if you wish you can make separate network for Modbus and configure ETH1 of the PowerPMAC see http://forums.deltatau.com/showthread.php?tid=199&highlight=eth1 and give it its own network. For example the IDE and your GUI would communicate through 192.168.0.x and your modbus through 192.168.1.x. Using the second ethernet port would result in less network collisions.

EtherCAT is a dedicated realtime network with its own network card that Delta Tau provides when the EtherCAT option is purchased. Transfers are performed during the servo cycle and it is highly deterministic. Modbus TCP is a software protocol on top of generic TCP sockets. It is non deterministic but can use one of the CPU's ethernet adapters. The system setup provided in the IDE already does EtherCAT generic I/O.

Attached is a simple IDE project udptest.zip that transfers data from user shared memory via UDP sockets. It contains a client and server that can be run from the PowerPMAC. It may be a good starting point for some test.

If there is anyone out there that wants to try to communicate between a Step 7 Siemens PLC and the PowerPMAC over Ethernet there is an open source project http://libnodave.sourceforge.net/ that does this. Attached is an IDE project SiemensPLC.zip containing a few of the samples from the project. The original code along with its documentation can be downloaded from http://sourceforge.net/projects/libnodave/files/libnodave/libnodave-0.8.4.6.tar.gz/download?_test=goal

Currently the IDE only generates a makefile for use with the POSIX skin. To work with the RTDM skin the -lrtdm option would have to be added to the makefile the IDE generates. If you had to have that skin right now you would have to manually add the -lrtdm to the makefile, then issue make from a command prompt, followed by manually copying the file to the PowerPMAC.

To clarify how we currently set the priorities. Our background thread which executes the PLC's and checks the watch dog is 50. The CPLC's which are triggered by the background operate at 51. The RTI CPLC is 75. A thread with a higher priority will preempt the scheduling of a lower priority thread. Also with the fifo scheduler if you do not release your thread ie. with a yield or nanosleep you will cause a hang.

You are correct redundancy is not in the master yet.

Case 1. -------- You have a PowerPMAC without Video option the usbmount package is present. This is will usually mount a FAT32 formatted card in the media folder. 1.) Check the folders /media/disk, /media/disk-1 or /media/disk-2 for the files on your SD card. Case 2. -------- If you have a PowerPMAC with the Video option automounting is handled automatically by the nautilus application in the gnome interface. You MUST login to the gnome interface Window manager for this to be in effect. nautilus will automatically mount the SD or USB stick in the /media/disk ... folder. Method 3 ---------- Manually mount the SD or USB stick for that matter somewhere. For example mount -t vfat /dev/sdb1 /mnt or mount -t vfat /dev/sdc1 /mnt will map the SD card or USB stick to the /mnt folder [quote='wfsteele' pid='1974' dateline='1308787581'] How do I mount an SD card? I found this post from 2009, but it doesn't work. Neither /dev/sdb1 nor /media/sd exist. [/quote]

There was an issue in the u-boot loader that was causing battery drain. The serial real-time clock part used in the design is an STMicro M41T62. This part has a full-time 32KHz square wave output that is connected to the TmrClk input to the processor. The default state for this square wave output is enabled so the output runs continuously when the board is powered normally and also from the battery. The TmrClk input to the processor goes to ground when the power is removed from the board/processor, and therefore the running square wave output is driving ground which drains the battery quickly. Way too much information but the bottom line is we upgraded to a newer u-boot loader along with the vendor changing the CPU to lower power and I am using a board that has held its date for ~2-3 months.

This should not be the case. The board should power up consistently. There are two improvements we made to the board, Q2 and Q3 are now FDS6690 FDS4435 which stay cooler. They were 4403 / 4894 . You can inspect your board to see what you have but this should not cause the board to not start up. In addition, Applied Micro upgraded the processor to a B revision that which stays cooler and uses less power.

By all means feel free to try it (after backing up your disk of course). A new version of debian was released at the end of February or the beginning of March. We use just the debian filesystem with a foreign kernel. The upgrade should keep our system intact. Just remember you must copy /.readonly/etc-tmps-mirror to /.readonly/etc and /.readonly/var-tmps-mirror to /.readonly/var after the upgrade.

Instead of using RS232 it is probable easier to use the PowerPMAC as a memory stick. Using a SHORT mini USB cable plug the PowerPMAC flash card into the PC. Navigate using Windows Explore to the removable media in ie. the F:\etc\network folder and examine the interfaces file. If you choose to edit the file from Windows you must use an editor that will work with UNIX files (that means something other than notepad). Also the cable must be very short or the the memory card will not powerup. Sometimes with longer cables you must unplug the cable from the PC and plug it in very quickly before the memory card will power on.

In the script file /.readonly/etc/rc2.d/S94KillGDM We do for i in {0..254} do echo "192.168.0.$i IP192_168_0_$i" >> /etc/hosts done

1.) Verify the items in the INI file that the IDE uses check that protocol is ssh, IPAddress=No Device Protocol=SSH PortNumber=22 UserName=root Password=deltatau C:/Program Files/Delta Tau Data Systems Inc/2.0/Power PMAC Suite/INI there are quite a few INI files you will see. 2.) Try changing your ip address. I know in linux a known_hosts file is saved and if you switch from card A to card B and they both have the same ip address the second one won't connect.

You can run as a non root user but it doesn't gets you anything since we mount the file system read only. See http://www.xenomai.org/index.php/Non-root_RT big fat warning. To run as non route you must 1.) Create a xenomai group with groupadd xenomai 2.) Add xeno_nucleus.xenomai_gid=1001 to boot parameter addmisc (Note: 1001 is the gid of the group created above) ie. From the bootloader via RS232 setenv addmisc 'setenv bootargs ${bootargs} xeno_nucleus.xenomai_gid=1001' 3.) Add deltatau to xenomai group by usermod command e.g. usermod -G xenomai,deltatau deltatau 4.) Change permission of /dev/rtheap chown deltatau:xenomai /dev/rtheap 5.) Change permission of /dev/mem chown deltatau:xenomai /dev/mem In addition, we did have to make a permission modification to our code that generates an ascii table corresponding to pmac. This modification will be available in the June/July Firmware Release to support running as non root. However, you can always sudo which works just fine and is a lot less trouble.

I was able to use the UM-730 a while back after changing a kernel option change if you are interested. In addition, I also prefer the VGA solution that we have designed as you have more choices for monitors as opposed to the digital HDMI/DVI only option we have. We would have to check on the availability of our VGA solution.

With ethercat we have performed update rates at 125usecs. I have not tried faster. The typical recv time is ~4 usec and the send time is ~ 7 usec. . With the beckhoff I/O ethercat is used between each I/O devices. In otherwords each terminal has ethercat built into it so there is a 100Mbit rate to each I/O terminal. With the WAGO I/O ethercat is only sent to the coupler (the module that takes ethercat ) The data is then sent to the terminals (the things that do I/O via K-Bus which I believe is RS422) which could explain why it was slow for your previous app. WAGO and Beckhoff codeveloped the original K-Bus I/O I was told which is probable why they look virtually identical. I don't see you having any speed issues if you were using Beckhoff I/O. However, you could have issues with the WAGO depending upon the K-Bus speed. I am no expert on WAGO's I/O but I think that is the case.