Debugging a FOURTH program 1992 era

In summary, the Bio tech company in Ma. manufactures a Feline Leukemia Virus vaccine. They currently use a TCS 6366 controller to control their pH in their 500 L fermenter. The 6366 controller has been giving them some erratic out puts, so they would like to program another 6366 as a backup. To program the controller they need to use a 486 PC running win 3.1 using an RS232 interface to the front of the controller. However, they have not had any success doing this. The program that gets uploaded to the controller is written in programming language FOURTH, and those of them working on this problem believe that there is a problem with the FOURTH program or the parameter file that
  • #1
jlorda
28
0
I work at a Bio tech company in Ma. We manufacture a Feline Leukemia Virus vaccine. We currently use a TCS 6366 controller(1987 vintage) to control our pH in our 500 L fermenter. The 6366 controller has been giving us some erratic out puts. We would like to program another 6366 as a backup so we can service the failing controller. In order to program the controller we have to use a 486 PC running win 3.1 using an RS232 interface to the front of the controller.
We have not had any success programing a backup controller. The program that gets uploaded to the controller is written in programming language FOURTH. Those of us working on this problem believe that there is a problem with the FOURTH program or the parameter file that loads with it. We have loaded other programs on to the controller with success (agitation and temp control). I will be attaching the two fourth files with this post. If anyone has any suggestions on the program logic or parameter files your thoughts would be greatly appreciated.
 

Attachments

  • F1U6.TXT
    1.5 KB · Views: 359
  • F1U6PARM.txt
    17.7 KB · Views: 389
Physics news on Phys.org
  • #2
Thank You in advance...
 
  • #3
That's rough. The files are mercifully short, but Fort is famous as a write-only language -- very hard to debug, especially when written in a terse style like you have here.

But I can't even start figuring out what it does, because it uses WORDs I'm not familiar with, not standard Forth: GT, GP, BN, ST, etc. Where are these defined? They're not in F1U6.TXT.
 
  • #4
This is all we have to go on. We have been trying to get our hands on the documentation that came with this program. But that was probably gone long ago. F1U6.TXT is just the program. The dictionary file is F1U6parm this gives the variables for the program from what I can tell. This is all we have to go on. Thanks for the reply.
 
  • #5
The program is supposed to keep the pH in the fermentor at pH 7.10 the set point(local set point). As the Bacteria grow the pH begins to drop below the set point the controller will open a valve to a pressure vessel that contains Sodium Hydroxide 5N for a given periop of time. There is also a subrutine for an acid addition but we never need to add the acid for this particular fermentation of recombinant ecoli.
 
  • #6
jlorda said:
This is all we have to go on. We have been trying to get our hands on the documentation that came with this program. But that was probably gone long ago. F1U6.TXT is just the program. The dictionary file is F1U6parm this gives the variables for the program from what I can tell. This is all we have to go on. Thanks for the reply.

I didn't expect that there was documentation. What I meant was that I don't even think this program will run at all in its present state. It seems to need an external library or a third file. (Anyone with more Forth experience is welcome to post to the contrary!)
 

Related to Debugging a FOURTH program 1992 era

1. How do I find and fix bugs in a FOURTH program from the 1992 era?

The first step in debugging a FOURTH program from 1992 is to thoroughly examine the code for any errors. This may involve using a debugger or manually tracing through the code to identify the source of the issue. It may also be helpful to consult any available documentation or resources from the time period to gain a better understanding of the program's intended function.

2. What are some common bugs that may occur in a FOURTH program from 1992?

Some common bugs in FOURTH programs from 1992 may include syntax errors, logical errors, or compatibility issues with modern hardware and software. These can all be addressed through careful examination and testing of the code.

3. Are there any specific techniques that can be used for debugging a FOURTH program from 1992?

One technique that can be helpful for debugging a FOURTH program from 1992 is to use a step-by-step approach, where the code is executed one line at a time to identify where the bug is occurring. Additionally, using print statements or logging can provide valuable information about the program's behavior and help pinpoint the source of the issue.

4. Is it necessary to have a deep understanding of FOURTH programming language to debug a program from 1992?

While having a thorough understanding of the FOURTH programming language can certainly be beneficial, it is not always necessary to debug a program from 1992. Many debugging techniques are language-agnostic and can be applied to any code, regardless of the language it was written in. However, having at least a basic understanding of FOURTH can make the debugging process more efficient.

5. How can I prevent future bugs in my FOURTH program from 1992?

To prevent future bugs in a FOURTH program from 1992, it is important to properly document the code and use best practices for coding. This includes writing clear and concise code, using meaningful variable names, and testing the program thoroughly before deployment. Additionally, staying up-to-date with modern programming practices and technologies can help prevent compatibility issues in the future.

Hot Threads

Recent Insights

Back
Top