KEJR

Hi Henry, There is also the delta tau init.d script, extra xenomai/DT libs and such, but I would think Debian would leave these alone in the upgrade. Anyhow I'll give it a shot at some point once the smoke clears on some of my current projects. Part of the reason for wanting to do this is that I've gotten an email from one of the Xorg input developers that the lilliput 10" USB monitor/touchscreen quirks should work with the newer evdev Xorg driver (i.e. not confused with the evdev kernel driver). I have to double check but I think the evdev driver in squeeze is fairly up to date. It would be good to keep fairly up to date on the distro as well. For what it is worth I have the Elo touchscreen on our first PPMAC machine right now powering up and logging in and firing up our programs without human intervention. The operator just has to hit some buttons from the touchscreen and it is off and running. They are used to this on our machines that have PLCs and touch HMIs and I didn't want to throw a mouse and keyboard at them on this type of small machine where extensive data entry is not needed (and we don't have space for it). Thanks again, KEJR

Hello again, I'm an engineer, I appreciate this information. Anyhow, can we get the bootloader updated, or are we stuck with this issue on these two boards? I guess I can rig an NTP time sync for now on these two boards. Its really only a pain at this point when I need to write new data to the disk and don't want old timestamps on everything. So far that is only installing packages and init scripts but at some point we'll add logging and things like that to the system. Thanks again, KEJR

Hi Henry, Agreed. I don't think it is a heat thing because it can happen first thing in the morning after being off all night. We do have the 4403/4894 chips on the board for Q2 and Q3. FWIW it should also be noted that we are using year 2001 vintage backplane boards and a fairly lightly loaded power supply (1 24V-IN/OUT and 1 Macro Master). Would it help in troubleshooting to monitor the 5V supply on the backplane with a scope at powerup, or are there other things to try first? Thanks again for helping me out, you seem to be the all-around PPMAC Guru. KEJR

What is Delta Tau's position on upgrading to the current stable version of debian? In the last couple months Debian put Lenny into the "OldStable" category. Other than the kernel are we free to experiment with an upgrade via debian APT, or is this going to break all of the PPMAC related setup? I have no pressing need at the moment, just a curiosity. Thanks, KEJR

I often have a problem where the CPU of the PPMAC does not boot properly. It doesn't even seem to get to the bootloader (As seen with the serial port attached). Is this a known problem? It seems I had seen this same problem with an evaluation PPMAC that we were borrowing from our distributor over a year ago. The System usually boots again if I remove power and then reapply power shortly thereafter.

Hello, I keep losing time on the PPMAC (two different systems). This is what I do and yet it comes back wrong after a while: date -s wed jul 30 19:41:00 EST 2008″ (set linux time) hwclock –systohc (set hardware clock time) Is there a different command to issue since this is an embedded PowerPC system? Thanks, KEJR

Davis, Thanks for the follow up. I did in fact use this method to restore to factory image and I like it much better. I don't think we will run into this much, but in early development things can get messed up if you are customizing the OS. That is one of the great things about this controller though .... the ability to customize it and write your own code the way you want to, or to use the pre-packaged approach if you aren't comfortable with C or modifying the OS. Despite our hiccups on our first application I can see this platform quickly paying dividends, especially on [but not limited to] the more complex machines that we do. Thanks, KEJR

Hello, For what its worth, I have a different way of doing it. If you write a "background C program" you should be able to open a socket and write your alarm strings as they occurr, at least from the C programming environment. This may be possible from CPLCs too. I am not suggesting that this is easier, in fact it is more complicated because you have to open a socket, etc. If your program is going to head that way eventually, you might consider this method. We are using this basic method, but with a linux FIFO file writing to our HMI process that runs on the PPMAC CPU itself. Its really not any different in concept though than writing to a socket. The HMI software has a thread that waits for data to come into the FIFO and then it displays it to the screen. Our realtime code controls what gets displayed and when, the HMI just basically writes it to the screen. In some ways the old method of having a global fault number, and storing your fault strings in the HMI is *alot* easier. From a machine programmer perspective I personally love the ability to type the error strings in my C code and download them to the PPMAC without modifying the HMI software *at all*. It all depends on what you are trying to do. KEJR

Hello, I think I have found some minor bugs int he backup/restore, but I wanted to ask before doing a bug report. When going to tools/backup I click on full backup and it barks that it can't mount the removable media. I then went out and bought a SD card and tried it again and it did not mount this correctly either. I then switched to the network backup option and it intially did not work and was complaining about mounting to /media/shared. /media existed, but was empty so I created /media/shared and it seemed to create my backup tar file from there OK. I don't know if I have an older filesystem install or what? This machine I was backing up is almost straight from the factory (new kernel and ppmac "firmware" .deb files for Feb 2011, and set to use DHCP). Just wanted to report that this was an issue for me and to make sure I wasn't doing anything stupid (always a possibility). Thanks, KEJR

Yes, as mentioned previously a relatively virgin ppmac CPU is working with ssh. I did not intentionally change the sshd settings, but I did at one point install the debian package "rsh-server" to get rlogin, rexec, etc. I don't know if debian modifies sshd when you do this. As I keep mentioning though, ssh connections are being made via PuTTY. Is there a reason why the DT IDE login would be different? KEJR

I think this is a good approach. I'll create a new user and allow them to sudo our HMI and xenomai process. One reason I'm looking into this is that it may make autologin very easy to do. The docs for gdm say they allow autologin at boot time by editing 2 lines in the gdm.conf file, but that root will never be able to auto login. So if I had another user and could autologin and then run our programs as root using sudo I think we are all set. I just didn't want to go down that road if I didn't have to, but it looks to be the simplest solution for now. Thanks, KEJR

I checked the ini files, but it seems that the dialog box used to connect doesn't always use these files. I did verify on the dialog box that the protocol was "ssh", port was 22, login was "root" and password was "deltatau". The IP address was correct as well, and is the same IP address I use to connect with Telnet, PuTTY, etc. I changed my IP address to a different one of the same subnet I'm on and it made no difference. I could still connect with ssh using Putty, but not the IDE. I have the RSA 2 key fingerprint that putty is reporting, is it possible that the fingerprint changed and the IDE doesn't know about the new one? The IDE never has displayed the fingerprint for me to check out and save to its equivalent of "known_hosts". The fact that I was never asked if the fingerprint is OK by the IDE is suspicious. KEJR

I have a couple more data points on the ssh issue. - I am able to connect from the IDE using ssh to a different ppmac CPU that is more or less as shipped from the factory (I upgraded the kernel and system deb files to match the Feb IDE on the nearly stock CPU). - Both CPUs can connect to PuTTY using ssh. - The ppmac scope tool cannot connect to the problem CPU using ssh or ppmacserver protocols (I didn't try the near virgin CPU). Are there any ideas as to how to debug this? I can set my ppmac CPU back to factory defaults but I have alot invested in the setup and it would take a little while to recreate that. It also bothers me that ssh and gpascii seem to work from other programs. Thanks, KEJR

I'm wondering what the official position is on user logins. Mainly this would be related to a ppmac user login (or autologin) to X windows and then starting HMI and C apps that are accessing the DT libraries on the PPMAC (the c apps would also be running xenomai threads). Should we just plan to always run as root, or does it matter at all? What about setting up "sudo" to run select apps as root? Thank you, KEJR

Brad, Thanks for the prompt reply. I just logged into the PPMAC with Putty and ran the "gpascii -2" program and was able to query variables just fine. I tried both symbolic and regular P vars with no problem. I also shut down all C applications of mine. I also just tried running the ppmac IDE on a different computer/installation with ssh login and it failed there as well. Here is the message log from the connect dialog: ******* Trying to ping to the device 192.168.169.40 Ping to the device 192.168.169.40 is successfull! Trying gpascii connection to the device 192.168.169.40. Gpascii connect failed for the device 192.168.169.40. Please Check the password. ******** The login in the default root with deltatau password (same I typed in with putty). I would suspect a network or ssh server problem, but the fact that ssh and "gpascii -2" works with putty kind of shoots that down [i think]. Is there a way to make the login message more verbose? It doesn't really tell you an error code or what it failed on (i.e. gpascii or ssh login, etc) Any other ideas? Thanks, KEJR

Hello, Has anyone experienced problems connecting via the IDE and ssh? I can only connect with the PPMACserver option right now, but I have a vague recollection that ssh used to work for me. I downloaded the putty ssh client for windows and it connects to the PPMAC just fine (nice program BTW, only one executable file.. no install). Any ideas to try? Should I just use the ppmacserver? Thanks, KEJR

How are you guys supporting different Ethercat devices? I met with the Beckhoff sales engineer for our area and he had mentioned that alot of devices come with an XML file to tell [traditionally] their twincat software what the device is. So one has to ask how the Power PMAC will interface to these devices. Are the XML files supported, or are they not needed due to the setup of the PPMAC? I am new to Ethercat, so I don't know the bus details yet. Currently we are anticipating having need to use the following products at some point: - Beckhoff ethercat terminal IO (analog, digital, maybe special functions). - Copley controls Xenus and accelnet drives. - Yaskawa Sigma 5 drives piggyback board. - SMC or Festo pneumatic valve bank communication module Does this seem like a reasonable expectation to set these things up with a power PMAC? Thanks, KEJR

I did use a variable name in a global include file in the scope trace list. For instance, it showed up on the list as "ptr.OilerValve" in my case, but when I started recording data I got the error message in the original post. KEJR

I did check the output window as you suggested and saw no errors of any type. Is there anything else to check? I'm not familiar with MySQL. The same delay is not present in the terminal window. KEJR

I ran into some other things and was not able to get back to this issue until now. I have disabled "auto list" and "parameter information in the "c language" section of options. I also connected a hardwire 100mbit connection and still I have an approx 1.5 - 3 second lag after typing in the editor screen. I think this might be slightly better than when using wireless, but I can't say for sure. There are no error messages in the output screen for both "build" and "deltataulog". Should the editor be doing anything intensive when I'm just typing code (especially with intellisense turned off)? As an additional debug note I put the project on the C:\ drive and the delay got noticeably better.. it is now maybe 0.25-0.5 second delay after entering a character. At this speed it is hard to quantify with any sort of precision what the timing is, but it is very noticeable. This implies to me that the editor is going out to the filesystem while I'm typing. Another note is that the lag does not seem to be apparrent or noticable when I am typing numbers. If I just hammer on "1234" over and over again it appears to be fast. If I do "asdf" it pauses after "a" and then "sdf" appears on the screen after the delay. KEJR

Hello, I'm using the Feb2011 release with firmware 1.3.0.0 In trying to use the scope tool to view an IO signal timing I get the following error in a dialog box after hitting the "play" button to start recording: *** /var/ftp/gather/GatherSetting.txt:2:16: error #31: invalid function in equation: gather.addr[1]-M8226->u.io:$a00010.8 root@192.168.169.40:/opt/ppmac# *** Is this a bug or am I doing something wrong? KEJR

Hello, We've been struggling to find a digital touchscreen monitor to interface to the PowerPMAC video HDMI option that works correctly. Most of the name brand touch panels out there are VGA. I've tried an Elo 15" with DVI and a Lilliput 10" widescreen with no success. I've tried two different Dell flatpanels that we had in the office and they both worked, but won't necessarily package on our machines with a touch interface and the space available. Currently I'm running with a Dell monitor and separate mouse sitting on a table next to the machine while we are finishing up development. So it makes me wonder, what are other people doing with their PowerPMACs and Hmi? I'm not interested in a "extra slot" PCI video card since we already own a couple PMACs with the USB-HDMI option. I think I'm left with a few options: - Try to see if a 10" lilliput or other HDMI compatable touchmonitor can be made to work. - Try to get a small 8-10" USB Displaylink touch monitor to work. - Get a USB-VGA adapter from third party or delta tau and pick from the more readily available VGA touch monitors. - Buy a small panel PC and try to make it "hardened" by read only filesystem with windows CE, linux, or windows embedded. Preferably this can be bought as a system. - Purchase a 3rd party industrial Hmi package and write a driver for it to use the gpascii protocol (I am thinking to try Red Lion because they supposedly have a general purpose programmable TCP/IP driver). Does anyone have a solution for any of the above working? Any other ideas? Thank you, KEJR

I was told that the EtherCat option incldues a special ethernet port, so you can't use either of the two ethernet plugs that are on the original PPMAC. I don't know the details as to why it is this way. KEJR

I use both of these functions in the Xenomai threads regulary. There are no hitches on time limits (well, other than float seconds). Keep in mind that Pause does wake up every realtime period, but it hasn't proved to be inefficient for me yet. [code] double GetTimeSec(void) { return 1e-6*pshm->ClockSF*u64btod(fclock()); } void Yield(void) { pthread_wait_np(NULL); } void Pause(float PauseTimeSec) { double StartTime; StartTime=GetTimeSec(); while((GetTimeSec() - StartTime) < PauseTimeSec) Yield(); } [/code] So once these are in your library you just call them when you need them. If Pause() proves to be inefficient at some point (you would probably have to have ALOT of threads sleeping for this to be a problem) you can rewrite it using nanosleep and check the data and do multiple nanosleeps if PauseTimeSec exceeds the limit. KEJR

That sounds good about the configurator. I like having options. As far as Ptr vars we are using them on IO because we can get at them via the terminal/watch as well as motion programs via their descriptive name. Additionally our internal library of C functions expects Ptr vars for IO related items. Typically we have anywhere from 64-256 IO points and a handful of analog IO if at all. So I don't anticipate reaching the 65535 limit anytime soon! :) If its quick to set up EtherCat/Beckhoff IO to do a loopback test that would be cool but we don't have a pressing need as of yet. We are torn if we want to switch to the ultralight/ethercat system on our next application or stick with the PPMAC-UMAC-Macro platform for now until the smoke clears. I'll call our distributor or you folks when the time comes that we need to decide. Thanks, KEJR