I/O board problem

[HillBilly]

Squarewave,

My LOGFIL.FIL shows the first event that triggered the INPUTIO.FIL and associated logic. My problem seems to be the input changing while the associated logic is being displayed in the G code window, it basically misses it. Oh yea, I am using Ver.14.8 and a Computer Boards 96 I/O PCI card.

Off the subject, how did the Mits. retrofit turn out? And where in TN are you located?

Darek

[squarewave]

HillBilly -

You have PM.

[squarewave]

Camsoft -

Thank you VERY much for your generous offer. It is great to know the extents you are willing to go for customer satisfaction. As you know, this is just a hobby for me and I do have to be very cost conscious since I don't generate any income. I do very much realize the value of the support you can provide and the importance of up-to-date software.

I will likely update the maintenance on this software in the future. Right now I am enjoying learning about the software and how to implement it on different machines and solving the various problems that arise.

Thanks again.

[squarewave]

I may have been making a mountain out of a molehill …

This problem showed up while I was verifying my input wiring to the Opto22 board. To make sure my I/O list was correct prior to writing logic, I physically actuated each input and checked for the relay number in the G Code window. I also verified that the LOGFILE entries matched the G Code window. When I made a physical change in the input, the logfile would show the running of the INPUTIO file, but only occasionally show the event that triggered it. Since it didn’t always show up in the logfile, I assumed that this meant the software didn’t internally update the status of the input. Tto verify my assumption, I added the following lines to the INPUTIO file:

IF#81=0THEN \57=0
IF#81=1THEN \57=1

I also added 57 to the variable watch list on the diagnostic screen. Then I manually actuated the limit switch attached to #81 and I found that the \57 variable was ALWAYS showing the correct status, even if the input status was not being updated in the I/O graphic, the G code window, or the logfile. So my initial assumption was wrong about the logfile containing a complete history of the events that occur on the machine.

I believe the problem may have not existed ….

[intrusion]

Squarwave,

Thank you for clarifying that for all of us, very clever. Good job.

From what I can see, is that while running diagnostics not only is the software continually writting to the LOGFILE.FIL file it is also displaying and updating the screen with all the same information for real time information. However this can, depending on the computers CPU speed, type and memory type plays a significant role on how fast the computer can actualy refresh things on screen. Plus many other factors regarding computer hardware and configuration. I do understand that to CamSoft refreshing the screen and graphics is secondary in nature and all processor speed is dedicated to the heart of the system where it matters most. From what you have tested and verrified you basically stated that this is the case. That's why I like this control.

I have also found a command that will allow you to suppress the screen update of all that logic while diagnostics is running. Issue LOGOPEN SILENT and all information will be written to the LOGFILE.FIL file, but not to the screen allowing this write operation to happen much faster.

At least that is how I see it.

intrusion