teaguehall

Hi Steve, thanks for sharing the updated manuals. I'm actually not experiencing any lock-ups currently, I'm just curious if the scenario I describe would put my application at risk. Essentially - if a realtime PLC were to get stuck in a loop waiting for a lock to be released, would a background PLC in possession of the lock be able to progress and release the lock? or would the realtime PLC starve all available resources?

I was searching for mutex lock support in the PMAC Script Language and stumbled across the Sys.Lock[i] variable in the user's manual. Per the "Power PMAC User’s Manual" version published May 15, 2019, it builds a case for the use of Sys.Lock[i] as a way to avoid incorrect register writes when two tasks occur concurrently operating at different priority levels (i.e. background PLC vs realtime PLC). In general, the example in the manual makes sense and appears to be working using some cursory tests. However, I'm trying to determine if there's a risk of deadlocks when tasks running at different priorities reference the same Sys.Lock[i]. Here would be the scenario: 1. Background PLC successfully obtains Sys.Lock[1] and begins running critical section. 2. While Background PLC is in possession of lock, Realtime PLC interrupts and attempts to grab Sys.Lock[1] 3. The Realtime PLC uses the convention "while (Sys.Lock[7] == 1) {} " and spins while waiting for the lock to be available. 4. Because the Realtime PLC is stuck in a loop waiting, the Background PLC never gets enough time to finish the critical section and release the lock. 5. We're now stuck in deadlock where Realtime PLC is waiting on Background PLC to finish, but Background PLC is waiting for Realtime PLC to finish since it's at a higher priority. Is this a valid scenario/concern? I guess I'm hoping it's not, but it seems like it would be based on my understanding on how tasks are scheduled on the PMAC. Any clarification would be appreciated!

Yes this is a hardware watchdog. The watchdog relay opens and the PowerPMAC becomes un-pingable. I'll look into the pp_disable.txt file. When do the commands in this file get issued?

We are using a PowerPMAC dual core 465 CPU (firmware version 2.3.2.5). When a project is loaded and running, a new download (via IDE 4.2.1.19) to the PMAC will often cause it to watchdog. This is very inconvenient, because it causes us to re-enable / re-home all of our machine motors. Once we power cycle the PMAC, the build and download succeeds. Is there something we can do to prevent watch dogging the PMAC on downloads?

Bump.

I'm not sure if my project uses encryption. Where would I check to see if its enabled? When right clicking my project, I have a "Build" and "Rebuild" option. I would assume the build option simply compiles things that have changed while rebuild is an explicit "rebuild all".

Any more thoughts on this?

So it looks like the compile time just takes a long time for everything (background process, libraries, realtime, etc.). However, it seems to do a full rebuild when I simply click the "build" option. I realize that if I were to change a single file that is linked against everything else, that could potentially trigger a full rebuild, but that's not the case here. Is this expected behavior?

Hi Dro, Yes its the build process that seems to be going slowly. The download is relatively fast so I don't have issues when developing PMAC Script Language code, just C code. When watching the output window, it seems to get stuck after "PowerPMAC variables mapped successfully" for a long time. After waiting ~7-10 minutes, it says that the build was successful. I'm curious if there are any build files.

Version 4 IDE with dual core (465) CPU firmware version 2.3.2.5. My computer is connected to the PMAC through a network. Does the compiler generate log files anywhere? I'd like to see what step is taking so long. It seems like adding code to the "library" folder and then linking to that increases compile time significantly. Curious if it's a linker issue.

When developing C code on the Power PMAC, I notice that the compile time is incredibly slow. For a modest size project, I've been getting ~10 minute compile times. This is incredibly painful. I recall there being some weird series of events where the compiler code/library code has to get uploaded from the PMAC for every compile. So essentially the compiler is dependent on the PMAC that you're building against and ultimately your network connection. Are there any tips for decreasing this compile time?

Good info to know regarding Sys.MaxMotors. I've been experiencing some weird issues that may have been caused by setting it unnecessarily large.

Hi there, My application currently uses a combination of comp tables. It would be desirable to monitor how much compensation each comp table is applying. I've run into an issue where I have multiple comp tables pointing to the same motor (e.g. Motor[1].CompDesPos.a). Because of this, it is difficult to determine how much compensation is be contributed by each comptable. What is the best method for monitoring a comp table's output? In the past, I've had to create "dummy motors" that simply exist such that I can point one of the comp tables at it. This way I can monitor dummy motor's CompDesPos register to see how much compensation is being outputted. This however feels a little "hacky". Is there a better method available?

Hi there, Is there a way to trigger data collection as a function of position instead of time? The gather buffer utility is a convenient way to collect data but is always triggered relative to the servo clock. Is it possible to configure the gather buffer to collect data as a function of position instead of time?

Any updates?

I support legacy code in which all EtherCAT variables are mapped in the following manner: ECAT[master].IO[io_index].Slave = position; ECAT[master].IO[io_index].Index = index; ECAT[master].IO[io_index].SubIndex = $1; ECAT[master].IO[io_index].BitLength = 1; ECAT[master].IO[io_index].Input = 1; However, some EtherCAT slave devices require their PDOs to be changed whenever a power cycle occurs. One of our drives for example doesn't broadcast certain information unless we write certain SDOs. What this means for us is that certain PDOs are not mappable until we write new SDOs. Once we configure the SDOs, it is necessary to perform an "ethercat rescan", otherwise, the PMAC won't let us map to the new PDOs. Essentially I need to wait for the ethercat rescan command to finish prior to trying to map certain PDOs when starting our machine.

Etherlab stack

When configuring PDOs on my EtherCAT network, I'm often required to issue the system command "ethercat rescan". This rescans the EtherCAT network such that the new PDOs become mappable. However, there is not a good mechanism that I'm aware of for determining when the rescan command has finished. Because of this, we are forced to put timers into our code that wait for some arbitrary amount of time before we try mapping the PDOs. Using timers like this is obvious bad practice and slows down our start-up process, however, I don't know of another way to monitor when the rescan command has completed. Is there a preferred method for determining when the rescan has finished?

It also seems that the "open prog" and "close" mechanism would be an easy way to load a motion program, however, it requires you to write your script program using L and R variables which would be somewhat annoying.

Referring to this 2008 forum post, (http://forums.deltatau.com/archive/index.php?thread-19.html) downloading single motion programs files seems somewhat difficult.. I'm curious if there is an updated method that doesn't trigger the PMAC to re-download the entire project. I've attempted the "download selected files" drop down option, however, this causes the project to reload which causes my machine to re-initialize. This is undesirable. Any help would be appreciated.

Curious about this topic as well. I can use the "ethercat download" command just find, however, trying to write an SDO using the ecatsdo function fails. My guess is it has something to do with permissions since the SDO index I'm writng to indicates it is rwr-r-

Hello, I've come across a download issue for a Power PMAC project. This project is being built for a dual core CPU PMAC. CPU Type: PowerPC,APM86xxx Kernel Version 3.2.21-powerpmacsmp Firmware Version: 2.0.2.14 IDE version: 2.1.0.107 Error: loading File: "ggerpp_enum.txt" Question: What exactly is this file and why can't it be loaded? When this project is built for a single core CPU PMAC, no error occurs. Thanks,

Hello there, I've run into an issue in which the PMAC IDE C compiler appears to link "C Library" code to all background programs regardless of whether or not the background program uses the library. This becomes an issue when a library requires an external definition. Example: Let's say I declare the following in a file called "library.h": extern void myAppSpecificFunc(); My library (library.c) calls this function. However, it is the responsibility of the end program to actually define the behavior. This should be fine since I will just make sure to define the function in whatever program uses the library. However, I've noticed that even background C programs that don't use the library are still being linked against the library. This causes an 'undefined reference to myAppSpecificFunc' error to be raised. The short term workaround is just to place a dummy define "void myAppSpecificFunct(){}" in all my background programs, however, it creates clutter. IDE version: 2.1.0.107

Hello, I've been running into various issues regarding 'uint64_t' and 'int64_t' data types. Specifically, functions that use these datatypes to pass data (either as arguments or return values) don't appear to function properly. I've also run into issues in the past where casting a uint64_t to a double simply does not work. The PMAC IDE seems to compile these just fine with no errors, however the code doesn't seem to execute as expected. So my question: does the PMAC IDE compiler officially support uint64_t and int64_t data types? If it doesn't, that would explain the problems I've been experiencing. If it does, I can further provide code samples that illustrate the issues. Thanks,

When calling subprograms from the command line, you need to specify your arguments and return values differently. So in the case of calling timer, it would be something like cx r0 = 60 call timer You assign 60 as the first function argument.