Citect #COM & KE500 Driver

Hi group, first post, please be gentle!!

I am working on a machine running Citect 5.21 and a SLC503 PLC. They are (were) communicating successfuly for 3-4yrs. Recently, I've been seeing more and more #COM faults in the Citect HMI screens, it's now at the point where it has inhibited production.

We've tried: Re-installing the Citect program, Reinstalling earlier "back-up" versions of the program which were running fine, Re-installing the entire Citect software package, Reinstalling the entire OS and software, Reinstalling the entire OS on a seperate PC, Trying a new SLC processor....all with no avail. And yes I checked the serial cable

I've tracked it down to the KE500 driver in Citect using the Citect Kernel functions,I can see the device error count indexing as the communications fail, but I don't know what to do/check from there. We're running Citect 5.21 SP-F.

Does anyone know of a Citect user forum, or any other sources to go to???

I'm at the end of my rope.....thanks for listening to my rant....maybe you'll have some ideas!!

Thanks,
JOhn

have a look at www.citect.com you should be able to find your way to the Citect Users List from there. When you seeing more and more does that mean that the coms failure was gradual and that for a period of time you were getting a mix of good coms and errors ?
Something else you might try. Create a new project in Citect and use Citect's wizard's to create the IO device etc if these work maybe you will be able to spot some small difference.
Could it be that someone has added some tags to citect that don't exist in the PLC eg. the N7 file in PLC only goes as far N7:100 and Citect has some tags addressed above that say N7:110 ?
When you say you have checked the serial cable how ? can you confirm that it works with RSLinx ?

If you havn't already have a look thru Citects help, from inside Citect Explorer select Help then Citect Help Topics then IO devices then browse down to your PLC type. I have attached screen dump showing relevant fields in related forms maybe it will help.

Thanks for your reply.

I've scoured www.citect.com and wasn't able to find a users forum...I'll go check again though...

I will try the new project idea tommorow, and see if I can find any minute differences...

I'm going to go though the offline tags tonight, and see if I can find any addressing issues...How might this effect the communications? Does the PLC write back a bit or something once it's accepted a value, and Citect is waiting for this confirmation?? Regardless, I'm checking into it.

I've checked the cable only by metering it.

I've been though the Citect help files, they were....helpful...they helped me get to where I am now, using the kernel, and observing the KE500 driver....


...Thanks again for your help!!!

John

check the thread again I updated my message

go back to www.citect.com and try to login (top left corner) maybe it will lead you to "new user"

cavediver said:

Thanks for your reply.

I've scoured www.citect.com and wasn't able to find a users forum...I'll go check again though...

I will try the new project idea tommorow, and see if I can find any minute differences...

I'm going to go though the offline tags tonight, and see if I can find any addressing issues...How might this effect the communications? Does the PLC write back a bit or something once it's accepted a value, and Citect is waiting for this confirmation?? Regardless, I'm checking into it.

I've checked the cable only by metering it.




I've been though the Citect help files, they were....helpful...they helped me get to where I am now, using the kernel, and observing the KE500 driver....


...Thanks again for your help!!!

John

Click to expand...

Don't know for sure but maybe Citect gets too busy retrying bad tags and runs out of time. My guess would be try to proove the cable can actually communicate serially but if you only have one slc then that will difficult as citect needs different protocol setup to rslinx. Have you (Can you) tried different hardware (com port ?)

Have at look at Archies Post in "Free AB SLC and Micrologix Software Utilies " you may be able to use it to test comms to slc

OK, so after another day on site, I feel as though I've made some progress, but it's also left me with more questions. Thankfully the machine is back into proper production!!!

So...the details...

I explored the Citect Kernel and was able to find the following error message recurring approximatly every 15 seconds while attemping communications:

"Tues July 10 13:40:21 2007 00:56:56.432 Error: Unit not responding
READ 0007 PORT1_BOARD1 PLC N7:27 13
Generic 00007 Driver 00000021 (0x0000000015)"

I interpreted this as though Citect was unable to read N7:27 from the PLC based on the second line. I changed the Citect Tag location information to N7:30 (the next unused N7 word) and also changed the PLC code accordingly. It worked....

...Which has led me to my next question, how/why did this work? How does the PLC handle the N7 memory area? Does it write to the same area over and over, and I've essentially worn this area out? or does it move the memory location around within its "total memory area"? I am having a hard time explaining this one...Perhaps someone can shed some light on it...


Thanks in advance,
JOhn

So if I understand you, you replaced the tag address N7:27 with the address N7:30 and the error went away ? I've never heard of anyone "wearing out" a memory area. I know that sometimes you can get strange errors like yours we recently had one where Citect will report an error in the kernel about a particular tag but in realtiy the actual bad tag seems totally unrelated. The only way we found it in the end was to delete tags one at a time (then replace if it didn't fix it)until the error went away, but these sort of problems tend to show in "new" or "beta" drivers.

Thats exactaly what I did....and I'm having a hard time explaining it to others.... ??? The only reason why I changed the address in the first place was to see if the Citect Kernel error message would change its indicated N7:27. I figured if I stoped using N7:27, and the error message remained the same, that I would need find another way to interpet the error message.

Again...

cavediver said:

Thats exactaly what I did....and I'm having a hard time explaining it to others.... ???
Again...

Click to expand...

What can I say ...Must admit when it happens to me an dI shrug my shoulders and say "must be magic" I do get strange looks. But youre definitely not crazy, similar things (and solutions) happen over here ..