I have an interesting problem with my I/O board. The software is not updating the input relay status consistantly. The really interesting thing is that the io card interrupt appears to be working correctly, because the INPUTIO file is being executed on EVERY relay state change, but the actual relay status (1 or 0) is being updated less than half the time. I can see the INPUTIO file being run in the gcode window, but only occasionally is #67=1 or #67=0 shown. When it is shown in that window, the diagnostic screen updates as well. If is is not shown in that window, then the dianostic screen does not update (makes sense). The Opto 22 relay is always showing the correct state.

Searching the web, I found references to disabled "bus mastering" giving problems with digital IO. I have tried bus mastering both on and off, with exactly the same result.

The computer is an 800MHz P3 HP Kayak running Windows 2000 Professional, and the IO card is an Adlink PCI 7296. I used the Camsoft driver.

I wish I could free up another computer to try this setup on.

Any insights would be GREATLY appreciated! :confused:

I assume you to mean the actual output is occuring when it should, but the monitoring is not occuring at the same time?
If this is what you are seeing, It is normal, even with most CNC and PLC manufacturers that the monitoring lags the closer to real-time I/O function, This is because the status software often does not attempt to run in real time, or close to it.
Al

squarewave,

This sounds like a very unique problem. When asking the others here, no one can recall a situation quite like you described. We also haven't heard of "bus mastering" before. So far we haven't run across an effect like this to look back upon for previous advice. We have noted similar effects that are related to screen refresh rates in Windows NT,2000 and XP that simply don't light up the bulbs on the diagnostic screen cause they change state too fast, but the history is always written as the printing of I/O # numbers catches up on the screen.

It might be best to call here so we can interactively ask you to perform some test. Also a LOGFILE.FIL file would be nice to have to review the history of events. We need to know what version you are running and whom you originally purchased from to get them involved.

Tech Support
CamSoft Corp.
(951) 674-8100
support@camsoftcorp.com
www.cnccontrols.com

Al -

Thanks. I should have said all of the outputs work fine. It is only the inputs I am having trouble with.

Camsoft -

Here is a snip of my Logfile:
>#69=1
(INPUTIO.FIL)
16:54:30
(INPUTIO.FIL)
16:54:33
(INPUTIO.FIL)
16:54:35
(INPUTIO.FIL)
16:54:38
(INPUTIO.FIL)
16:54:41
>#68=0
(INPUTIO.FIL)
16:54:44
>#68=1
(INPUTIO.FIL)
16:54:47
(INPUTIO.FIL)
16:54:49
>#67=1
>#68=0
(INPUTIO.FIL)
16:54:52
(INPUTIO.FIL)
16:54:55
(INPUTIO.FIL)
16:54:58
>#66=1
(INPUTIO.FIL)
16:55:00
>#66=0
(INPUTIO.FIL)
16:55:03
>#66=1
(INPUTIO.FIL)
16:55:06
>#66=0
(INPUTIO.FIL)
(INPUTIO.FIL)
16:55:08
(INPUTIO.FIL)
16:55:09
>#66=1
(INPUTIO.FIL)

It is easy for me to actuate any one of the limit switches on the toolchanger and still see the screen. The INPUTIO entries occur each time I either close or open a limit switch, but as you can see, only a few have a #66=0 or similar entry. I have also tried several different switches to make sure it was not an isolated channel.

My version number is 14.2.

Squarewave,

I have the same problem. When in diagnostic mode if I hit the output# for the tool load
solenoid, the tool moves from the magazine at the same time the logic is being displayed in the G code window the tool carriage reaches the load proximity switch and is NOT displayed on the I/O map. If at this time I hit a output#, say work light on, the I/O map updates to show this input now.

I am surprised Camsoft does not remember me and this complaint because I sure had it.

Darek

We should point out that these are not the same I/O problems. One is not getting the hardware interrupt and the other is not refreshing the screen.

Squarewave is related to hardware,drivers or electrical as he has discuss with us directly.

HillyBilly is related to a simpler Windows issue covered by
QUESTION 222
We have noticed the virtual lights on the digital I/O panel do not always respond in real-time.

Tech Support
CamSoft Corp.
(951) 674-8100
support@camsoftcorp.com
www.cnccontrols.com

Just to give an update to steps I have taken to fix the unrecognized input problem:

Did a fresh install of XP Pro on the same computer by removing the 2000 hard drive and wiping the replacement HD. Installed the Camsoft software from the Camsoft V14.2 CD. I installed NO other software - just XP and Camsoft. After installing the Camsoft drivers for the Galil and Adlink boards, I experienced the same problem.

I decided that maybe it was the PCI bus in the HP, so I "borrowed" my wife's computer, a Dell running XP Pro. This computer has never had any Galil or Adlink software installed. I installed the Camsoft software and hardware. Same problem.

Back to the original computer. I decided that it might somehow be the I/O card. I purchased a new Adlink PCI 7296, installed it, same problem.

I tried a different Opto22 interface board (I have old series optos installed, so I tried a G2 series) and different cabling. Same problem.

Camsoft believes this is a driver problem or a memory conflict problem, and I am working my way to believing it since I have systematically eliminated most of the potential hardware problems. But, why would a fresh install with no other software loaded have a driver/memory problem?

I/O on the Galil board (limit switches) seems to work fine, so this problem is isolated to the Adlink hardware/software. This problem makes most of the machine features useless, since my toolchanger and table indexing routines that all WAITUNTIL will hang.

PLEASE, can anyone think of anything else to try?

HillBilly -

Thanks for sharing your experience. Does your logfile look similar to mine with regard to having INPUTIO entries without a #XX=0 or 1?

Its my understanding that if the #XX=0 or 1 doesn't show up in the logfile at the time the INPUTIO file is run, then the software has not recognized the new state of the relay, regardless of what the diagnostic screen shows. Is that true?

Did you try to do update Windows Update on-line? That is always and in most cases fixes problems relating to hardware/software issues. Can you load windows 98 or 2000 and try that?

What kind of relays are these? What kind of relay operation is it: latched or momentary on-off-on? I assume these are just simple low voltage inputs to monitor the state of the machine?

I don't know much about the details of circuits, but is there a clean cut-off of the circuit when the relay operates, or is it too fast, or accompanied by a spike (no diode snubbers on it)?

CNCadmin -

The original computer I tried was Win2K - it is pretty up to date, but the windows update is a good thought - I'll give it a try. The two WinXP installations were SP1. Camsoft has changed some drivers for SP2, so I thought it best not to go there.

I have been considering trying a WinME installation, since it is not NT based. I don't really want to, since I won't want that computer to stay WinME very long. My Camsoft CD has both 2000 and XP installations, so I feel like I should be able to get one to work.

Hu -

Yes, these are simple limit switches that stay on as long as the tool is considered up or down. There is a separate limit switch for each position. The Up switch goes off as the tool moves downward. When the tool is down, the Down switch activates. I used the original 24VDC lines that went to the original PLC and rewired them into the Opto22 board. The LEDs on the Opto board always reflect the correct status of the switches, which does not always match the last entry for that IO number in the logfile.

Squarewave,

These are serious problems and safety concerns.

After reviewing the files you sent to us a couple of weeks ago we can say that we never have we seen a problem like this before, nor can we even conceive how to duplicate it.

We truly understand that your very price conscious and you pieced together this system from E-bay and various web-sites. You're using a mixture of two old versions of the software that we can't trace back where they came from or guess on what affects this would have.

We would normally refer you to your dealer/installer to come over an investigate this on-site, but there was never a dealer assigned to you and you're not in our database as on official customer.

One clue is that we use our own I/O card assembly level written drivers that bypass Windows to talk to the card through the PCI bus directly. We inform others that have had purchased the cards directly from the manufacture that they must not allow AdLink or any other installation CD driver to be registered with Windows or installed. This results in Windows conflicts, usually displaying I/O Lib errors messages, but never has or should an I/O trigger and the system not catch it. This is at the root of some mixed or conflicting drivers or even a hardware problem that has no parameters or settings to configure. It either works or it doesn't. What bothers us most is that it is accepting the driver and working randomly with out error messages, so it is seeing the hardware interrupt sometimes, but skipping it other times.

This is all the more reason to keep your software version current with the various MicroSoft service packs and DLL upgrades that come out frequently. We have updated our software drivers over 20 times to match all the versions of Windows OS from Windows 95 to XP.

We strongly urge you to become a CamSoft customer and get a registered copy of the latest software. We will even offer to take the computer and other various hardware boards including the I/O board and set it up for you free of charge. We will send the system back to you fully functional with one year of direct free tech support and free software updates.

If you accept this offer, we can transfer the license into your name and do this for only a expired maintenance fee, rather than buying the software as a new customer. This is only a fraction of the cost and we will log you in the database as if you were always a customer of CamSoft.


Tech Support
CamSoft Corp.
(951) 674-8100
support@camsoftcorp.com
www.cnccontrols.com

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

HillBilly -

You have PM.

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.

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 ….

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. :boxing:

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