KEJR

I could be wrong but from what I understand the UMAC ARM board is the same CPU card as the CK3E. Maybe check the manual for that to see how to backup or if there is a post here on backing up the CK3E KEJR

Hello, Just use an "int" declaration. Memory is really cheap and your compiler could be aligning the char values to 64bit boundaries anyway. If all you need is a multistate value then you would be better off using an enum which is an int under the hood but with a little extra type checking and syntactical sugar. KEJR

I haven't worked with them in years but it was my understanding that the cplc's were nothing more than predefined c program threads running under xenomai realtime. I don't see why the command() function would be different under cplcs as opposed to "background C apps" unless the cplc's run under a different context such as kernel mode threads. You might give it a try. I would do the interfacing to the motion buffer and coordinate system stuff in a "background C app". Just much more power and control over how it executes and how many threads you can have in one process. I'd advise against doing any communications in rti, this needs to be deterministic. Maybe I'm misunderstanding you? KEJR

I've resorted to doing my own makefiles starting with the DT generated one. I've written an in house library that compiles to a static library "mylib.a" type of file and other projects link to this. The thing that stinks is that I have to connect to a PPMAC of the same architecture and build a dummy project before I execute a make operation. So far this is easier than creating my own build environment on my filesystem but at some point that may be more attractive.

I see what you mean now, it sounds like a good solution. The 25% CPU sounds kind of high. Is this due to the delta comparisons and saving the last state operations on a large block of data? I'm in the middle of implementing a "two part" system like this (realtime TCP relay so to speak) with message queue's. This has been in the last week or so (its taking alot of rewriting in my library/api code). So far its been running well. I'm using short text messages to synchronize data over TCP and be able to deal with all different data types and not worry about byte order and data word issues and all of that stuff. Its not as efficient as binary transfer but going to a change of state /event based design helps out alot especially if you have data thats not changing much and "scanned" at a low rate like 50-100ms intervals. Dealing with floating point is the most difficult (significant digits, comparisons, etc). That's tough about the bad memory. I'm still having issues with some of the early PPC405 units we got but the newer ones seem OK and I'm not sure we have had any with bad memory yet. Knock on wood but the CK3E ARM based PPMAC is running excellent so far (fanless, in my office). ;-)

I can't comment on the headers since I didn't write them ;-) All I know is that I've been told that we could use the command interfaces to start motion and what not from C programs (i.e. background C programs). This is just my opinion but I would not recommend doing anything in the RTI involving non-deterministic behavior (like a command processor). I am not sure what Delta Tau has to say about this but I would guess they feel the same given that header comment. YMMV

Thanks for the notes Eric. I personally prefer to get the date only at bootup which is why I didn't suggest using NTP. I don't have a good reason for this, just mainly didn't want to mess with the clock in a RTOS system after its booted. NtpDate is being phased out but is still available and configures really easily if you follow these instructions. It should be noted that there are ways to install NTP and configure it to behave like NtpDate (assign time at bootup only), I just haven't had time to experiment with that because NtpDate works for me. This wasn't meant to be a HOWTO for getting atomic clock accuracy, but more of a way to get it to a more reasonable time in the absence of a functional battery backed clock. I didn't have to edit the apt sources on the CK3E. If you are doing this on the PPC405 I recommend the HOWTO that I wrote in 2015 and subsequent contribution from member SHansen. "HOWTO: Changing APT to point to debian archives" http://forums.deltatau.com/showthread.php?tid=2056 Thanks, KEJR

Hello, I don't think this HOWTO is limited to the CK3E but I found a few problems related to the CK3E such as needing to issue an update to the apt package manager and what not. This entire process should be similar if not exact for other PPMACs. I updated my PPC405 PPMAC disk image years ago so I can't remember exactly what it needed. NOTE: you will need to have your PPMAC able to access the internet. Verify by pinging some internet sites prior to starting this process if you haven't done so already! First, fire up PuTTY and connect to your PPMAC as root user. The first step after that is to make the root disk writeable: root@192.168.xx.xx:/# mount -o remount,rw / Now we have to update the package list. For some reason ntpdate is not listed for the CK3E unless we do this next step. root@192.168.xx.xx:/ # apt-get update (update takes several minutes, be patient) Now we issue the command to download and install the packages that ntpdate needs. There will be a handful of packages installed in addition to ntpdate and this is OK. root@192.168.xx.xx:/# apt-get install ntpdate (answer yes to install the packages) Now we need to copy the information that was installed in /etc and /var to the actual disk. Even wtih root as readonly the /var and /etc locations are mirrored in RAM to the tmpfs-mirror locations shown below. Be very careful how you type this and make note of the paths since the copy command is issuing relative paths. root@192.168.xx.xx:/# cd /.readonly/var-tmpfs-mirror/ root@192.168.xx.xx:/.readonly/var-tmpfs-mirror# cp -a * /.readonly/var root@192.168.xx.xx:/.readonly/var-tmpfs-mirror# cd ../etc-tmpfs-mirror/ root@192.168.xx.xx:/.readonly/etc-tmpfs-mirror# cp -a * ../etc If you want to change from UTC to your local time do this: root@192.168.xx.xx:/opt/ppmac# cp /usr/share/zoneinfo/MyCountry/MyTimeZone /.readonly/etc/localtime Of course, change the zoneinfo path to your appropriate time zone. For me it was /usr/share/zoneinfo/America/New_York since I am on the east coast of the USA Now mount as readonly so we know all the packages are written to disk and just to be super safe. root@192.168.xx.xx:/# mount -o remount, ro / Now we can reboot. You could power off, but just reboot to be safe. root@192.168.xx.xx:/# reboot Issue the date command to verify your setup: root@192.168.xx.xx:/opt/ppmac# date Thu Aug 17 10:54:59 EDT 2017 root@192.168.xx.xx:/opt/ppmac# That should be it. Please respond if I've missed anything. KEJR

Hello, I've been putting SDCards into the PowerPC based PPMACs for some time now and they always configure to /dev/sdb This makes it easy of course to mount the first partition by configuring fstab to mount the first partition by device name, i.e. /dev/sdb1 I always mount to a folder I created named /mnt/sdcard When using the CK3E PPMAC it seems that the system configures the internal flash drive differently depending on whether or not a USB flash key is plugged in! This makes it difficult to edit the /etc/fstab file to use a specific device path. I started to use the concept of the unique identifier to mount the USB disk, and it worked, it is just that on a production machine you want to be able to hot swap in a USB drive if you are having problems, or at least I do! :o) So anyway, I stumbled upon a method to mount the USB drive by the USB port its plugged into. The system creates a path in /dev/disks/by-path that represents the bus and port it is plugged into. This doesn't change by USB disk type, brand, or configuration AFAIK. So, assuming all of you USB disks are formatted for the same filesystem (I use ext4 for reliability) it should "just work" for all drives. Heres how to do it: 1) Connect to the PPMAC with a good SSH terminal like PuTTY or even the debug virtual serial port (the micro USB connector on the top of the unit). Go to Device manager if you don't know what port it is assigned by windows. PuTTY is easier though and if you are doing work with the PPMAC it will be your best friend eventually so you should get used to it :o) 2) Verify that you have the same USB port ID as me: ls /dev/disk/by-path Assuming your disk is partitioned you will see this line amongst others: platform-xhci-hcd.0.auto-usb-0:1.2:1.0-scsi-0:0:0:0-part1 This seems to be consistent no matter what type of USB drive I plug in to the front panel port. 3) make the root partition writeable mount -o remount,rw / 4) Edit the fstab file that will persist at reboot pico /.readonly/etc/fstab Once in the Pico editor copy the following line to your clipboard (CTRL-C) and then paste it into the PuTTY terminal using the right mouse button (You could type it if you are masochistic). /dev/disk/by-path/platform-xhci-hcd.0.auto-usb-0:1.2:1.0-scsi-0:0:0:0-part1 /mnt/sdcard ext4 defaults 0 2 a typical fstab line for a second disk looks like: devpath mountpath fstype options 0 2 Before saving the fstab file change the filesystem type to that of which you have partitioned your USB device and modify the mount point path to something that you like (but make sure there is a directory for it beforehand.... you can do that in a later step). I recommend ext4 and a directory in /mnt 5) Write file and exit Pico (CTRL-O, answer prompt, then CTRL-X) 6) Create the mount point if you haven't already, e.g. mkdir /mnt/sdcard 7) Make the drive readonly mount -o remount,rw / 8) Restart the PPMAC reboot 9) After a little while Restart PuTTY and login again and you should have a writeable flash drive available! root@192.168.xx.xx:/opt/ppmac# mount | grep sdcard /dev/sda1 on /mnt/sdcard type ext4 (rw,relatime,data=ordered) root@192.168.xx.xx:/opt/ppmac# ls /mnt/sdcard/ lost+found root@192.168.xx.xx:/opt/ppmac# I hope this helps. I tried this with two different USB flash drives formatted for EXT4 and they both booted and mounted to /mnt/sdcard for me. KEJR

I know I'm late to this party but this is how I see the best way of handling your problem. My Assumption is that all of your threads writing to shared memory are running at the same priority level. This is easy to do with CPP because you assign them the priority you want them to have. Be careful of the PMAC facilities such as kernel tasks which will inherently run on a higher priority. I'm not sure how motion progs and "PLCs" play into the game but in general these are not writing to anything that isn't already atomic (i.e. the 64bit CPU writes even a double float atomically). That said, lets say you have, 5 realtime threads running at the same priority. All of them read and write to shared memory, including arrays, objects, whatever. Since they are all at the same priority you won't have a problem with the other threads preempting/interrupting the write of an array or object, for instance. Now we add a 6th realtime thread that is going to do the work of detecting what shared memory objects changed and packing them into a format that can be shipped over the network. Instead of writing to the network you will write to a realtime FIFO pipe or message queue. So far we have no worry about thread preemption and don't require any mutex operations since all threads are at the same priority. Now we have a thread running as a "normal" linux thread (non realtime, secondary mode I belive its called?) that sits there reading the message queue and then delivering it to the TCP connection when data is available. The message queue or realtime FIFO is designed to work this way and will guarantee that you get your data without tramping on the higher priority threads with mutexes and other things that can be problematic in that sort of situation. You should be able to do the same thing in reverse, that is get data over TCP to a linux thread and then pipe it through a message queue where it then gets read by the same "6th" [in my example] realtime thread and written to shared memory, possibly in between scans for changes or whatever frequency you like. If I were to start my application from scratch I think I would go this route. I may even change it so that every data "tag" inherits from a base class that has a boolean to indicate when the data has changed so that you can scan through a list of all different types of objects and only look at one boolean to know when to update the object over the network. All write access will have to go through methods so that the "changed" bit can be set when it is changed. This can be pretty efficient. You might need some sort of throttling to handle the data that rapidly changes, but this could be as simple as the period of time you sleep in between data scans, for instance. Going from HMI to PPMAC is probably not going to need much throttling because it tends to happen at "human" speeds (button input, etc). KEJR

I would check to see how the python calls are intended to work. That is to say that some functions/methods act like a shell ... they start the program, wait for it to exit, and return the exit status. If this is the case for your python functions then calling gpascii will effectively "hang". You will need to be able to start the program with a function/method and then call other functions to write and read to stdin and stdout respectively and the gpascii program won't exit until it either crashes or you give it a cancel signal over stdin (CTRL-Z I think??). I hope that helps? KEJR

Hello, I've recently upgraded the IDE to 2.2.1.25 with the patch and got a sample application running through the IDE's default project using the CK3E as a target CPU. I then took the makefile and adapted it to work with my application (i.e. not using the IDE). My application makes frequent use of threads and I was getting a linker error that it couldn't find libpthread.so and that I should include it explicitly in the commandline. If my google searching is correct it seems to have something to do with a newer behaviour of the linker [ld] not automatically including shared object dependencies by default and that you should pass them to the linker commandline going forward. I ended up passing -lpthread in the linker options and it compiled fine. I know the makefile does alot of wrapping of thread functions to handle the xenomai magic and want to make sure I'm not going to get hosed down the road. I haven't had time to run the application just yet but I will give that a shot tommorrow morning. Thanks, KEJR NOTE: This Modification seems to work in all the testing I've done since the original post.

Hi Dave, I am very excited to see how the ARM system runs and your experience is the first I've heard of from another user. I take it this is the u-etherlite board that is in production now? I've only seen picture with a brief writeup of the USB A style connector on the front panel. The writeup I've seen says that the LED will turn green if you plug it into a PC (RS-232 adapter mode) and if you push the little button witha paper clip next to it that the LED will turn from green to orange (Where orange is mass storage mode and used to backup/restore the PPMAC filesystem, etc. ). This begs alot of questions, such as does this mean that you can only hook it up to use a rs232 TTY if the USB port is only hooked to a host PC? How does this effect you if you want to use USB peripherals (Keyboard, mouse, USB-serial, USB FLASH, etc) with the PPMAC as a USB host? Are there any other USB ports on this system? I've only seen photos of the front/side projection with one USB port, one EtherCAT, and one ethernet port. Presumably there is at least a power plug for 24V somewhere on the top or bottom. I know from Talking with Delta Tau and reading about the CPU architectures that there is an endian issue between the 460/465 and the ARM CPU. I believe the 46x Power CPUs are Big Endian and the ARM's are little endian. Are you doing anything with 8/16/32 bit words, perhaps in the shared memory? If you are converting from 64 or 32bit words down to bytes (or vice versa) you are going to have a problem running your code unaltered. Here is a good article on endian-ness in relation to C code that I found: https://www.ibm.com/developerworks/aix/library/au-endianc/ Its definitely worth considering. KEJR

The PPMAC does have rich ethernet capabilities and Insight supports telnet, raw ethernet, and modbus TCP. Depending on what you are doing with it you shoudl be able to communicate one way or the other. You may have to write a C program to do your interfacing but this is builtin nicely with the rest of the environment.

Hello, This is probably not the issue but I wanted to mention this: Are you doing your reads and writes with entire words? The reason I ask is that I had an issue with shared memory accessing P vars by byte (i.e. memcpy() ) and instead I rewrote my code to use double type pointers so that the CPU would read the entire 64 bit double as one CPU instruction. Be careful here because it could be something in a standard library (C or C++) that is doing it as in my case. THAT SAID .... I can't see how this would be DIFFERENT just by changing the processor affinity. I would dive into some xenomai reading for running on multiple cores with shared memory. Maybe there is something special that needs to happen with shm interfaces? KEJR

HI Windell, So far I have had no issues. If anything it would probably be at bootup trying to reach the server but I don't know that for sure. Since your application relies on the correct time you would want to check the date/time for validity of some sort.

I know this is an old posting but I wanted to point out that I've used an IEEE-488 to USB adapter to send SCPI commands to some data acquisiton equipment and power supplies using a product from a company called Prologix, LLC (I was using windows embedded 7). One main feature of this product is that it uses a USB to serial port driver. I can't say for sure if it would attach to the power PMAC but it would be worth a try since other popular USB-serial drivers do work. I don't know if that would solve the original problem mentioned in this post but I thought I'd pass this information on. KEJR

Hello, The linux distribution used on the power PC based PowerPMAC is debian Lenny and it has been out of the support chain now for years. When I first started using hte PPMAC I could go out and install a package or two that I liked or needed for a particular thing I needed to do. For some number of years the main archives have been down. Here is how to get back to where you can install software using apt-get once again: First make sure you have a backup of your disk image (if not stock), some of these steps if done wrong will botch your system up. First log into your system as root, using puTTY or other SSH shell and make your root disk writeable: # mount -o remount,rw / Next, edit your /etc/apt/sources.list file to point to the archived repository. In this example I will use the editor called pico. #pico /etc/apt/sources.list deb http://archive.debian.org/debian/ lenny contrib main non-free deb http://archive.debian.org/debian-security lenny/updates main #apt-get-update #apt-get install debian-archive-keyring #apt-get install gdb Next we need to copy all of the newly modified files in /etc ramdisk to the real disk "readonly" location so that changes will be restored upon powering back up. We also want to make the root filesystem readonly once again. # cd /.readonly/etc-tmpfs-mirror # cp –a * ../etc # mount -o remount,ro / For good measure, lets reboot: #shutdown -r now Of course to install additional packages later you can repeat this process but should leave out the parts about updating sources.list and installing the keyring, etc. I hope this helps others. KEJR

This is a bit confusing because C++ is a superset of C. Does your existing c++ code make use of a lot of "C++ ONLY" features such as objects/classes and function/operator overloading, passing by reference, etc? If so then you will have to port it to straight C.

I think Brad hit the nail on the head, but I'll just add a few things. Once you have a ssh connection as a transport established you should login, execute GPASCII which will run indefinitely as your command interpreter through stdin and stdout. I'm not familiar with that ssh library but you should be able to write and read to the port connection through a stream. Connect to the PPMAC and run GPASCII and you will see how it works. You may need to use a program like Hercules (a program you should have if you are doing serial port or TCP programming) to view the non printable ASCII characters. If your ssh library only allows you to execute single lines of shell input and expects the program to return immediately with a return code then you need to look into another ssh software. KEJR

Hi Dave, I tend to agree with the above statement. I think it could help people to see the information from a fresh PowerPMAC point of view and be organized by basic sections and from a beginners perspective. Sections like Data Types, Basic Syntax, and program types. I'd leave out details and advanced features for the most part. the other confusing thing is that the example programs have some not so great things in them. For instance the example listed by Steve in the above post has a static buffer (i.e. known size array) declared using malloc() and it uses #defines in the C code as opposed to the global PMH files and including pp_proj.h, and a while() loop to handle return code on the Send function (this one puzzles me). From my perspective this is very confusing and could lead the new user who may not be an expert C programmer toward using poor programming practices. I can kind of see where they might have been coming from the angle of "look how flexible this is" but I would prefer to see using something like a very clean C program using a "best practices" approach. Please take this as constructive criticism (all DT guys reading this). I would not mind helping with an example C program that I consider to be clean and best practice and post it for review, for example. This is kind of getting off the track of the original post, but if there is any interest for updated manuals or examples maybe we can do a new post? Let me know if anyone is receptive to this.

Could you guys post these documents with the other documentation on the website or something like that? It would never had occurred to me to look for the PDFs under an example program directory. Maybe put them in a documentation folder in the install directory and perhaps even a shortcut to the docs during install? These would have helped me a bit when doing my first subprogram.

Hello, The script mode is in response for a request of mine to have a way of using P variables by name rather than calling a function to get/set the values. I had also expressed concern that ptr vars (M vars in turbo PMAC speak) and global vars (P vars) could be easily interchanged in the user code to potentially bad results. The script mode uses an enumeration for ptr vars and globals are of type double since they are accessed directly in shared memory. So if you try to pass a double type to a function expecting an enumeration you get a compiler error instead of a runtime error, which obviously is much more preferred! So when you do the script mode the IDE generates the pp_proj.h file with some #ifdef statements in it. One of these conditions is the script mode. Open the file and read it, you can tell what is going on. I think the DT guys did this because they wanted to provide this functionality but they didn't want to break existing programs. I can respect that. So I hope this explains why your code only works with script mode defined? I find the manuals confusing. They are very hardware/instruction oriented. Like many things Delta Tau there are a half dozen or more ways of doing the same thing. Many of the manual entries and examples speak of the register and local variable assignment but in the IDE all of this is taken care of for you under the hood. I don't need to know which local variables my named locals are assigned to, I just want it to be taken care of by the compiler in much the same way as a C compiler hides register/stack variables from you. DT has done a decent job at making the motion and PLC programs more "C" like so keep this in mind and ask questions if something looks odd.

I needed 10^307 years... now I'm hosed. What about leap year? ;-) (Joe wins!)

BTW, I used double type return because that is what many of the PPMAC variables are. replace with int if you like (or bool if you have C++). KEJR