When there is a queue error in a subroutine, it is difficult to find out which subroutine it came from, as the Message Queue doesn’t show the subroutine name. This can be an issue when debugging nested subroutines. Is there an easy way to find out which subroutine had the error? Would it be possible to get the subroutine name in the Message Queue?
Hi Philip,
There’s a ticket in for this issue (it only shows up for those strategies with NESTED subs, FYI). In the meantime, here’s how you can decode that _s34796:
When PAC Control compiles the strategy, it creates a plethora of files in the strategy directory. The .crf file is text so if you view its contents in NotePad, you will find some lines that look something like this:
/ +++++++++++++++ SUB Name=“AddFive” Short name=“_s2” ++++++++++++++++++++
Happy decoding!
-Mary
Okay, thanks. This project is using nested subroutines.
Just a heads up on some other issues:
I’m running into lots of crashing when debugging nested subs, unfortunately I can’t reproduce the steps, it is kind of random. PAC Control (9.6d) crashes when stepping through code occasionally and Soft PAC even hung on me once and I had to kill it.
I’ve also found that I frequently need to run a “Compile All” before downloading or I will get errors about missing something or other when downloading. Sometimes it does download, but my subroutines are never called - just get skipped over or I will get an error in the queue “Bus error”. Stopping and starting SoftPAC, running a Compile All, and re-downloading gets it all going again.
I know this isn’t terribly useful without steps, but I haven’t been able to narrow down anything reproducible.
Bummer. Sorry about that. FYI - I’ve forwarded these details/issue to our PSG team, since we’d like to get these fixed, asap.
In the meantime, if your strategy is causing a “Bus error” on SoftPAC, it’s likely to cause a reset on a PAC-S or -R series controller. Have you run any of your nested-sub strategies on a hardware controller?
I ask because, usually a reset on one of those will create a little text file on the PAC’s ftp server called “diagnostic-info” which is kind of like the autopsy report. A better analogy might be the black box on an airplane (you can get a clue as to what happened just before the crash).
In any case, if any of your hardware controllers have that file sitting there on the ftp server, please send it in to support@opto22.com ASAP because that’ll help figure out where the trouble is (and sometimes help us figure out how to get specific steps).
Thanks,
Mary
Unfortunately, I haven’t tried it on a hardware PAC yet - probably won’t be able to try that out until next week.
