Phew, that's quite some program with a lot of complexity. I am not sure how much useful help you will get because it really is ( for me anyway ) just too much to take in and understand without having to study it in a lot of depth.
For a first programming exercise it's an ambitious task to take on, and that lack of experience shows in what you have. That's not a criticism in itself ( we all write bad code when we start, and I probably still do ), but it doesn't help in trying to understand what's going on here, and it makes following the code very hard. An example ...
- softstartloopa: for b1=1 to 6
- if sstart = 0 then softstartcheck
- if ocl = 0 then ocll
- if ilock = 1 then intlocka
- if thermal = 0 then ttripa
- if onoff= 1 then psuoff
- if b1>=6 then softstartoff
- if b1<6 then softstartloopb
-
- softstartloopb: goto softstartloopc
-
- softstartloopc:
- :
- softstartloopd: next b1
-
- softstartoff: low maincont
In this, 'IF b1>=6' will cause a jump out of the FOR loop, while the following 'IF b1<6' will always be true, and goto's a goto to a label which immediately follows, so the whole lot is redundant. The program flow goes all over the place. I won't say it makes one want to give up the will to live, but it does make it really hard to follow what the code is meant to be doing or to determine where it may be going wrong.
It's not particularly clear what is going wrong from your description in your first post. Downloaded programs don't ( under normal circumstances ) simply reset or get lost for no good reason but they can stop working when input signals or conditions are not as expected or combinations exist which haven't been catered for; they are the bane of programming.
The thing you need to do is to determine what does work, what doesn't, and where the program is when it stops doing what's expected, and from that you can hopefully work out how it got there and more importantly why. Often, not an easy task, and in a complex program like this, it could well be anywhere.
Debugging is a mix of science ( logical analysis, prediction etc ) and art ( experience, intuition, inspirational and lateral thinking etc ). It is sometimes easy, sometimes very hard, and especially so within a real-time system where debugging can alter what needs to be observed.
While we have the code and a description of I/O, it is not clear to me how the controller is meant to function, and I'm not familiar with such PSU's, so it's hard to tell if you have a design flaw or simple coding error.
The approach I would take is to trim the code back to its absolute bare minimum, removing test modes etc, and get that to work ( in an environment where faulty code won't destroy the PSU ). I'd do debugging by liberally adding SERTXD's to report where the code was getting to so its flow can be traced and verified as correct. Once that code is working, move on to adding more code ( for interlocks, testing etc ) incrementally, debugging each addition and checking the earlier code operation hasn't been compromised.
With a unique project like this there is the problem that no one else can test your code for you or properly simulate what is meant to be going on. I wouldn't recommend such a project to anyone unfamiliar with programming, but with a solid design to start from, by incrementally coding and verifying operation during development a satisfactory outcome should be achievable. The worst case is where ( because of the real time nature of the system ) complex code has to all work first time; it rarely does and it's a nightmare to deal with. Any silly error or even typo means nothing works, and it's hard to see why or where. The best approach there is to make what needs to work as least complex as possible.
I think that trying to debug the code you have, and determine where it is failing, is likely doomed to failure or will take a long time. The quickest route to a solution is to consider that code 'a prototype', use the knowledge you have gained so far, and re-write the code from new again. Many programmers spend their lives doing that, and it's a legitimate and valid means of development, and how most code is developed in its early stages.
It's possibly not what you wanted to hear, but it's probably the best way to move forward. I've spent hours banging my head on walls and pacing offices trying to understand why things don't work as expected, only to discover that, "Okay, let's start again", takes much less time and delivers a solution which does work.
