george.kontogiorgos

Hi moha_sa, I'm currently working in a fast data acquisition application using native gather inside a C Background Program. The Background Program runs on Linux, inside the controller. If you are trying to write some file, the fopen path argument (to create a file handler for fprintf, where it will write to) must exist on controller's Linux, not on Windows where IDE runs. Are you checking fopen's return value? /*For more information see notes.txt in the Documentation folder */ #include <gplib.h> #define _PPScriptMode_ // for enum mode, replace this with #define _EnumMode_ #include "../../Include/pp_proj.h" int main() { FILE * fp; fp = fopen ("/var/ftp/gather/file.txt", "w+"); // Check if file handler is not corrupted if(!fp) { printf("Error trying to open the file, is everything ok?\n"); return -1; } fprintf(fp, "%s %s %s", "Write", "some", "stuff"); fclose(fp); printf("File was written successfully!\n"); return 0; } This snippet is a simple file writer that check it. Connect to the controller via SSH, run the above program and check if /var/ftp/gather/file.txt was created correctly after "File was written successfully!" message from the program. Now you can use pscp (Windows) or scp (Linux), or another tool, to copy the file to your Windows host where IDE is running. A strong evidence that there is something wrong with the path argument is fopen returning NULL value. Besides that, the IDE program folder isn't synchronized with controller's folder when you Download the project, it's just a copy (to /opt/ppmac/usrflash/Project). Also, the project folder inside Power PMAC is write protected and you may modify the permissions to write to it (Honestly I don't like this idea). If you want to have some more control to the gather process (and complete AAnikstein's code) I did some manipulation with fork and file descriptors: // Create gather process pid_t pid=fork(); /* Child process */ if(pid==0) { // Open gather output file int gather_file_fd=open(file_path, O_WRONLY | O_CREAT, 0777); if(gather_file_fd==-1) { return 2; } // Make stdout of gather program as input of output gather file int gather_file_fd_dup=dup2(gather_file_fd, STDOUT_FILENO); close(gather_file_fd); // Give this process to gather control, like a parasite int err; err=execl("/usr/bin/gather","gather","-w",NULL); if(err==-1) { return 2; } } else { /* Parent process */ return pid; // Return child PID } Doing that you are changing the gather output from stdout to the file and also you have the PID of the gather program instead of system command that do not allow you to manipulate gather process. Regards, George

Hi Eric! Thanks for replying me. Yes, I do know that this is a good pratice, thanks for the advice. I think it would not be a problem if the CaptCompISR just enable the gather. I had this idea but I was trying to avoid any delay between the interruption and enabling the gather.

Hello, I would like to use it on CaptCompISR routine, is it possible? What is the best way of enabling gather from interruption?

Hello I know that we already have the execution of CaptCompISR function when position matches to the preset value. I would like to set the interrupt source not as position but as some GPIO, User Flag, Hall input or some other hardware IO. In my point of view the ISR is an elegant solution when compared to polling some input, which is the way I'm thinking to run a program when some input is triggered. Thanks in advance, George

Hi Eric, Thanks for the tip. I was using to circumvent the problem on my API: GetResponse("Gather.PhaseEnable=2", gpascii_response, 100, 1); But maybe your command is faster than mine since GetResponse has to manipulate the return from the command. I was thinking in just initialize Gather. structure on the begining of my program with something like that // Initialize Gather. struture Command("Gather.Enable=0"); Command("Gather.Enable=1"); Command("Gather.Enable=0"); // Use gather structure directly pshm->Gather.Enable=2; Thanks, George

The sad Emoji was a mistake made by a set of special characters toghether, I'm sorry about it.

Hi Eric, As your suggestion I did some tests as follows. Test 1 I issued the folowing commands (on that order) on the terminal: $$$ Gather.Items=1 Gather.Addr[0]=Sys.ServoCount.a Gather.Period=1 Gather.MaxSamples=100000 And then I ran my C Background Program with the following content /*For more information see notes.txt in the Documentation folder */ #include <gplib.h> #define _PPScriptMode_ // for enum mode, replace this with #define _EnumMode_ #include "../../Include/pp_proj.h" int main(void) { InitLibrary(); // Required for accessing Power PMAC library pshm->Gather.Enable=2; //Put your code here CloseLibrary(); return 0; } And then the PowerPMAC crashed (the red arrow 😞 Test 2 I reseted the PowerPMAC with $$$, opened the plot window and wait it initialize. After that I closed the plot window and set my gather parameters (Just to be the same as the last test since plot window sets Gather.Period and Gather.MaxSamples when it opens). Then I ran my C Background Program (the same as Test 1) and everything goes fine. Conclusions from Test 1 and Test 2 Opening the plot window before using pshm->Gather.Enable=2 on the C Backgroud Program works fine (the PowerPMAC does not crash by enabling gather on a C program). I suspected the Gather.Enable=1 followed by a Gather.Enable=0 that is on plot window Gather Settings area. That was difference from my configuration from terminal and configuration from Plot window. This lead me to Test 3. Test 3 I did exactly the same as Test 1 but adding Gather.Enable=1 followed by a Gather.Enable=0 on Initial gather configuration on IDE Terminal: $$$ Gather.Items=1 Gather.Addr[0]=Sys.ServoCount.a Gather.Period=1 Gather.MaxSamples=100000 Gather.Enable=1 Gather.Enable=0 Then I ran the C Background Program and the PowerPMAC did not crash. Conclusions from Test 3 PowerPMAC Test 3 lead me to the conclusion that setting Gather.Enable=1 or Gather.Enable=2 (value 2 I tested earlier on my first post of this thread) run some initialization on Gather. structure. So I did Test 4 to know if setting Gather.Enable=0 and run the C Background Program crash the PowerPMAC. Test 4 I reseted the PowerPMAC controller and then issued the following commands into the IDE Terminal Gather.Items=1 Gather.Addr[0]=Sys.ServoCount.a Gather.Period=1 Gather.MaxSamples=100000 Gather.Enable=0 Then I ran the C Background Program and the PowerPMAC crashed. Conclusions from Test 4 Setting the same value (Gather.Enable=0) to register and running the C program crash the controller. The last test, the test 5, I just tryed the last option for enabling gather (Gather.Enable=3). Test 5 I reseted the PowerPMAC controller and then issued the following commands into the IDE Terminal Gather.Items=1 Gather.Addr[0]=Sys.ServoCount.a Gather.Period=1 Gather.MaxSamples=100000 Gather.Enable=3 Gather.Enable=0 // Stop rotary gather Then I ran the C Background Program and the PowerPMAC did not crashed. Conclusion Changing Gather.Enable value from 0 to something different from IDE terminal may initialize something inner the controller that allow pshm-Gather.Enable works fine on a C Background Program. This is what Plot window does when it initializes (we can see on Gather registers changes). Obviously I do not know in fact what the Plot window does and maybe it do some inner controller initialization. Thanks, George

Hi wehg, I did some tests with lower sample frequencies and I didn't had issues with loosing samples too. I was performing gathers using phase interrupt source with 10 kHz of phase frequency and Gather.PhasePeriod=1 which led me to a 10 kHz of sampefrequency. When I used Gather.PhasePeriod>=3 I didn't loose any sample, neither at begining nor ath the end. Maybe your sample frequency is sufficient slow to don't show this kind of problem (I would appreciate if you could test your setup with higher sample frequencies). Unfortunately I don't know the exact answer to your question and I would like to know too. I was searching on the forum some stuff related to gather and Background Programs and I found this. Maybe the best option for us is writting our own gather_csv which manipulates the buffers and files in a way that fits well for our applications. Regards George

Hello, I am unsuccessful trying to trigger data gather from a C background program. I wrote the following program (capp1.c) to debug the problem: /*For more information see notes.txt in the Documentation folder */ #include <gplib.h> #define _PPScriptMode_ // for enum mode, replace this with #define _EnumMode_ #include "../../Include/pp_proj.h" int main(void) { InitLibrary(); // Required for accessing Power PMAC library pshm->Gather.Enable=2; CloseLibrary(); return 0; } Then I built, downloaded and save the project. After that I restarted the controller with $$$ on IDE terminal and run my background program via SSH connection (./capp1.out). The controller then suddenly stops responding on IDE and the controller`s watchdog LED lights up. When I first do some gather via IDE terminal (Configure everhing, Gather.Enable=2 and Gather.Enable=0) , the background program starts working (it sets correctly the enable register and gather the desired data). I have the hypothesis that the commands issued from terminal do some initialization on gather feature but I do not know how to track it. This idea of initialization comes to me when I realized that when I do Gather.Enable=2 on C program the Gather.Index does not automatically erase as it happens when the same command is issued from IDE terminal. So I manually erase the buffer and reset index as follows: /*For more information see notes.txt in the Documentation folder */ #include <gplib.h> #define _PPScriptMode_ // for enum mode, replace this with #define _EnumMode_ #include "../../Include/pp_proj.h" int main(void) { InitLibrary(); // Required for accessing Power PMAC library //Put your code here // Disable any running gather pshm->Gather.Enable=0; // Set sample counter to zero pshm->Gather.Samples=0; // Erase buffer with gpascii command (Index points to buffer's position 0 after clear) GetResponse("clear gather", gpascii_response, 100, 1); // Start gather pshm->Gather.Enable=2; CloseLibrary(); return 0; } Another point is that I could successfully enable the gather at first time after reset by using: GetResponse("Gather.Enable=2", gpascii_response, 100, 1); Instead of: pshm->Gather.Enable=2; I tryed on two different controller's architecture: Type: POWER PMAC BRICK CPU: PowerPC, AMP86xxx Firmware: 2.5.4.0 And Type: POWER PMAC BRICK CPU: arm,LS1021A Firmware: 2.6.0.0 Thanks in advance, George

Hi wegh, The way I found to circumvent the problem of rotary gather was issuing the following command to the PowerPMAC linux terminal (using pipe): gather -p -w > "yourfile" Once gather program armed, using Gather.PhaseEnable=2 to trigger the gather and setting large number on register Gather.PhaseMaxSamples to not reach the end of the file quickly. At some point I stopped the gather with Gather.PhaseEnable=0 and issued Ctrl+C on PowerPMAC linux terminal. In another test I wait the gather to reach the Gather.PhaseMaxSamples and issued Ctrl+C on PowerPMAC linux terminal. On both situations the gather didn't lose any samples. Nevertheless, I could not successfully do the rotary gather with the option Gather.PhaseEnable=3. I also create a custom phase loop to be able to sample the Gather.PhaseSamples register (Setting Gather.PhaseAddr[0]=Gather.PhaseSamples.a is not possible) by assigning its value into a global variable so I can acquire it with PowerPMAC gather tool. void user_phase(struct MotorData *Mptr) { pshm->P[100]=pshm->Gather.PhaseSamples; } For now it solves my problem, but I think that future implementations would be in risk by this limitation of Gather.PhaseEnable=3.

Some information about my controller Type: POWER PMAC BRICK CPU: PowerPC, AMP86xxx Firmware: 2.5.4.0

Your tip led me to the following error: 10.20.56.18:/opt/ppmac/gather_csv# ./gather_csv -p -w -u /var/ftp/gather/test1.txt Too many command line arguments. If using a long file name enclose it in " " ie. "long filename.txt" Proper usage : gather_csv [-p] [-u] [filename] -p optionally gather on phase -u upload last gathered data -w wait until for gather to started -r upload last rotary gathered data Remember that I'm trying to perform a rotary gather and the option -u is used to upload gathered data on buffer. How could be the usage with -r (which is the option for rotary gatered data)? I would like to keep the option -w, so I could start the gather and take the first samples on a triggered gather for example.

Eric, I think that your suggestion fits on my application for now. Thanks.

Hello, I'm doing some experiments with data gather system and I relized that the gather program missed some samples. The pointer Sys.PhaseSamples presented a more samples number than line numbers on the gather text file. The difference is about 20 samples but it is not repetitive for every gather. The gather setup was did on IDE Terminal as follows: Gather.PhaseEnable=0 Gather.PhaseAddr[0]=Sys.PhaseCount.a Gather.PhaseItems=1 Gather.PhasePeriod=1 Gather.PhaseEnable=1 Gather.PhaseEnable=0 Gather.PhaseMaxSamples=500000 After I issued the gather program with wait option on Linux: ./gather_csv -p -w > /var/ftp/gather/test1.txt Triggered the rotative gather on IDE Terminal: Gather.PhaseEnable=3 After some time, usually when Gather.PhaseSamples > Gather.PhaseMaxSamples (To check the rotative buffer), I stopped the data acquisition: Gather.PhaseEnable=0 Gather.PhaseEnable=1 Gather.PhaseEnable=0 The last gather gave me Gather.PhaseSamples=32818200. The first line of data acquisition file test1.txt (After Waiting to phase gather) is 71693224 phase counts and the last line of the same file is 104511413 phase counts. The difference is 32818189, so threre are 32818190 samples because we have to take the first line in account. So this data acquisition lost 10 samples this time. I don`t know if there is any delay on the gather system at the begining or at the end of the acquisition due to initialization or finalization of the program respectively and this lead to missing some samples. The difference between one sample and another is 1 in every line (I tested it with a Python script), according to Gather.PhasePeriod=1. This led me the conclusion that these lost samples are not at the middle of the gather. I would like to know why I`m losing samples and understand it to set up things correctly for future applications. Thanks in advance.

Hello I would like to know if there is a way to share variables (e.g. Global Variables) between PowerPMAC Script Language and embedded Linux on controller. Actually, I was unsuccessfully trying to create a C program and compile it with GCC to access the content of a Global Variable address as the example as follows: #include #include int main() { int * pointer; pointer = 0xa9304b20; printf("%d\n", *pointer); return 0; } Where Sys.P[100]=$a9304b20 The program crashed by Segmentation Fault error and I'm searching for new ways to access these variables on the memory by Linux.