1746-QS Fault Issue

I am having an issue in the field with the 1746-QS module connected to two Axis. Currently the issues is a feedback issue on both axis (1 & 2 are flashing green to red, Power & Flt are Green, 3 & 4 are not lit)

Some more background Detail.

This system is connected to a Resaw Linebar with both cylinders to ensure that the linebar (the device being moved) maintains its alignment to the bandsaw. In the past we have done this with a TDC2000 controller, but we decided to try the 1746-QS due to its increased # of axis (i believe) and the hopes that there would be some time savings in programming, and increased simplicity. Although, honestly I have no experience in working with the TDC 2000 (the previous controls designer is at a different company now) but have been told that it is a challenge.

Basically we have two cylinders c/w valves wired on site, and have been able to move them with the Hydraulic configurator previously. We were able to tune them and have them perform as expected with the configurator.

However, as of yesterday the QS card is showing this fault, the program isn't showing any data back from the Temposonics (both of them at the same time). My initial thought was that there could be a power / fuse blown, however the power for both 15V and 24V have been traced, and nothing physically has occured to change the temposonics or the PLC setup to cause this. The power supplies appear to be functioning correctly according to our meters.

I'm kind of at a loss for what would cause a sudden loss of feedback, the card and PLC have both been 'rebooted' with the card being pulled and placed back in the same slot.

Does anyone have an idea where we should check next (or some good resource for troubleshooting this card)?

We have found that this card has limited acceptance and use but obviously it is a little late to change cards at this point.

Any help is greatly appreciated.

Thanks,

Riley Smith
Lindsay, ON

Divide and Conquer

This is simple. Connect the transducers to one of the old TDC200s and see if you are getting valid feedback. If not there is something wrong with the MDT ( magnetostrictive displacement transducer ). Next replace one of the MDTs with a know good MDT to see if the transdfer fault occurs.

A common problem is to have the CONFIG field not configured correctly. Make sure the start/stop or gated PWM options are configured correctly. You should have indicated EXACTLY which error bits are on since there are 3 of them. If the MDT overflow bit is on the problem is almost certainly a configuration problem.

Finally, get a scope and check the interogate and return pulses. The on-line help shows what the signal should look like.

I can't offer advice on the QS module, but I noticed one thing in your post:

the card and PLC have both been 'rebooted' with the card being pulled and placed back in the same slot.

Click to expand...

I realize you may not be doing this, but I wanted to remind you never, ever to do that to an SLC-500 controller with the power on. You'll fry the controller and/or the modules. Only the 1756 ControlLogix can pull that remove/insert under power stunt.

Thanks for the assistance.

A Couple of clarifications : We are not able to utilize other ldt controllers as this is the only one on site.

Also, now, the valves are not responding to either closed or open loop commands using the Hydraulic Configurator software.

Finally, I appreciate the reminder on the SLC powerdown requirements, and assure you they are being followed.

Thanks for all the help.

Oops

It sounds like you have blown the DC to DC power supplies for the isolate I/O or you have blown the FPGA that controls the I/O.

I have some new Questions regarding the QS module. It turns out that there was likely something 'buggy' with the module itself. I was able to acquire / borrow one off of a customer that wasn't using theres currently.

However, we have another question regarding the logic for the 1746-QS module (we being myself and the Controls person on site.)

We are utilizing axes 1 & 2 on the module in synchronized movement. We are moving two 12" displacement cylinders with Bosh Rexroth Proportional Valves (not sure of model # as i am writing from my home) with MTS G Series Start / Stop LDT's.

We are able to get movement accurately and in synchronization. However, due to a misunderstanding of the desired operation, there is currently a one shot preventing the move command from being issued continuously. However, these cylinders are in a Sawmill environment on a Linebar Resaw and when there is an impact there is some movement and the cylinders do not 'seek' their position again. What we are going to try for a single attempt tomorrow is running the system without the 'One Shot' and hoping that the cylinders properly 'seek'.

My question is, does anyone here have any experience with something similar in concept, and if so, is the One Shot rising our only issue, or should we be using some bit setting (or something of the likes) to tell the cylinders to be always looking for the location until they are told to go to another location?

Also,
If we remove the one shot, is the system going to move sporadically due to being constantly given movement commands?


Any and all help (previous included) is / has been greatly appreciated.

This is the last stretch of our startup issues that we have been having (so far in this startup have had following 'bad luck' :
1 Dead Panelview (mysteriously stopped working)
1 Dead 125hp Softstart (mysteriously stopped working)
1 Dead QS Module (no longer functioned correctly, was tunable after being tuned))

The site has 'substantial' power issues, and they are dong 'minor' (emphasis on 'minor') power conditioning (read : lightning protection only)

We have warned customer, and they do not want to spend any $$ on it (although it is minor as almost 15-20 k in $ items have mysteriously stopped working) so we continue in hopes of better luck.


Thanks,

Riley Smith

I know a little about the QS

maexio said:

We are able to get movement accurately and in synchronization. However, due to a misunderstanding of the desired operation,
there is currently a one shot preventing the move command from being issued continuously.

Click to expand...

? This is not clear.
A 'G'o command should only be issued once per move. NOTE, you must change the data in one of the six command fields to generate a new command. Writing the same thing over and over again has no effect.

maexio said:

However, these cylinders are in a Sawmill environment on a Linebar Resaw and when there is an impact there is some movement and the cylinders do not 'seek' their position again. What we are going to try for a single attempt tomorrow is running the system without the 'One Shot' and hoping that the cylinders properly 'seek'.

Click to expand...

? I am still confused. What exactly are the commands you are giving?

maexio said:

My question is, does anyone here have any experience with something similar in concept, and if so, is the One Shot rising our only issue, or should we be using some bit setting (or something of the likes) to tell the cylinders to be always looking for the location until they are told to go to another location?

Also,
If we remove the one shot, is the system going to move sporadically due to being constantly given movement commands?

Click to expand...

The QS doesn't see the ladder writing to the output registers. This can be done every scan without any problems. The QS can only see the CHANGE in the output registers so you must change one of the output registers to generate a new command.

A problem can occur when an error occurs. You can't simply re-issue the same command because the new command will look like the old command and the QS will not see anything change. In case of an error you should change the 'G' command to a 'g' command or back to a 'G' command to re-issue the command.

The QS has a last command buffer. Each scan the QS compares the six command area registers with the last 6 command area registers. If any of the six registers are different the new command is issued and the output registers are copied to the last command buffer. This is done on a axis by axis basis.

Are you following the QSExample?

Peter Nachtwey said:

? This is not clear.
A 'G'o command should only be issued once per move. NOTE, you must change the data in one of the six command fields to generate a new command. Writing the same thing over and over again has no effect.

Click to expand...

Thank you. This is new information to me. Apparrently our 'One Shot' was completely useless.

Peter Nachtwey said:

? I am still confused. What exactly are the commands you are giving?

Click to expand...

I genuinely do not know for certain as I am only corresponding by phone and do not have a copy of the code. We are however, able to get the two cylinders to position accurately to their location, but they do not correct when something 'impacts' the linebar and causes them to move out of position / or out of acceptable position accuracy... What we would like is to have the cylinders position in synchronization (as they are physically connected) and then have them 'seek' to remain in that position and correct for any 'non-code / instruction based' position changes. This will allow them to counteract the effect of Press Rolls forcing large wooden squares against their linebar (the item they are positioning, and are connected together to.) We have done this successfully using a TDC 2000 Controller in the past, but foolishly, I decided to change our standard in hopes of making it easier (hindsight is 20/20 they say)

Peter Nachtwey said:

?The QS doesn't see the ladder writing to the output registers. This can be done every scan without any problems. The QS can only see the CHANGE in the output registers so you must change one of the output registers to generate a new command.

Click to expand...

Thank you, this is new information to me. I / We were not aware of this before as all we have to go off of is the User Manual and it is difficult to understand all of the functions completely. Is there another resource I / We should be looking at for more information (other than PLCS.net of course!)

Peter Nachtwey said:

?A problem can occur when an error occurs. You can't simply re-issue the same command because the new command will look like the old command and the QS will not see anything change. In case of an error you should change the 'G' command to a 'g' command or back to a 'G' command to re-issue the command.

Click to expand...

I could try this, but i'm not certain it will provide the 'seek' functionality that I'm looking for?

Peter Nachtwey said:

?The QS has a last command buffer. Each scan the QS compares the six command area registers with the last 6 command area registers. If any of the six registers are different the new command is issued and the output registers are copied to the last command buffer. This is done on a axis by axis basis.

Click to expand...

Thank you, the more understanding we gain on this QS, the better.

Peter Nachtwey said:

?Are you following the QSExample?

Click to expand...

Yes, I believe so, as it is the only code we had to go on.

Thank you for the assistance. I still need it to operate in a vigilant positioning / seek function. I'm not certain how to do this, but it is critical to the function of the machine, as it will always be recieving various amounts of counter positioning force depending upon the material / operator, etc, so we can't just correct for it (unfortunately).

All help is / has been greatly appreciated.

Thanks,

Riley

Another Question about the QS Settings

After more review of the QS documentation, I find that there is an Integrator mode setting. I cannot verify, but am afraid that my initial programmer set it to Only operate during Decel and Inposition as opposed to Always.

I am also assuming that this is the setting that causes the QS to 'Closed Loop Position' that is: Read the location and adjust the valve to ensure it is at or approaching 'In Position'

Does anyone know exactly what the Integrator Mode value in the Command Mode Word does in layman's terms?

Any help is appreciated, and I apologize for the lack of code / additional frustrations caused by the limited information. I am passing on all information that I have as I am not actually on site to support this, and the person that is does not have Web access.

Thanks,

Riley Smith

You should have the QSCFG in front of you. If you double click on the mode field a dialog box will open that allows you to change the mode to always on. If you are synchronizing axes the mode field should normally be 0x0091. If you go to the on-line you will see the bits in the mode field are defined. Two of the bits define the integrator mode.

The integraor mode bits have nothing to do with whether the axis is in closed loop mode or open loop mode. It only specifies how the integrator will work in closed loop mode. I normally keep the integrator in always active mode which is the default. This is important in your application because you need to track the target throughout the motion profile, not just when decelerating or stopped.