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?