Project crashed overnight

[AabeckControls]

Unfortunately, only the SLC5/05 supports 38400, the 5/04 max's out at 19200.

It doesn't seem to be a graphics problem though - I can load pages quickly most of the time, just occasionally it takes a while. And sometimes just entering a new keypad value that doesn't change any graphics and the Programming page (that isn't graphics intensive) & changing the step number should only change one BasicLabel and one MessageDisplayByValue.

And it doesn't happen every time, most of the time new step #'s are updated in both objects within a second or less, then suddenly it takes 10 seconds. Same thing with changing forms - which shouldn't rely on the DF1 comm's at all.

[Godra]

Archie, a question for you:

Even with subscriptions disabled on all instances of DF1 driver, BarLevel and BasicIndicator controls are still showing "Failed to get processor type" message.

Is this expected behavior?

[Godra]

Just to let you know that after removing a comment from "Return &H78" in GetProcessorType function (AllenBradleySLCMicro.vb) testing of this project was far faster and smoother on my end (besides for the Controls form, which still took a bit longer than other forms to initially load).

Everything else I could do was flawless including switching between and closing of the forms.

This still might not mean much in case of enabling subscriptions and connecting to a PLC.

[Archie]

Even with subscriptions disabled on all instances of DF1 driver, BarLevel and BasicIndicator controls are still showing "Failed to get processor type" message.

Is this expected behavior?

This is a known behavior in some of the drivers. It has been fixed in some, but not all of the drivers. What is happening is that on startup, it is essentially trying to get the information about the PLC address. The DisableSubscriptions just stops it from reading updates of its values. In order to get the address information, it must know whether it is a PLC5 or SLC/Micro and that is where it is trying to get the processor type.

The line you uncommented will force it to always use SLC/Micro style commands and essential disable PLC5 compatibility. This also keeps it from trying to go to the processor to get the processor information.

You figure that for each item on the form, it will try to send a packet to the processor then wait for a response. This will cause the long delays when it is not connected to a processor.

[Godra]

This is what I had to do in older versions of AHMI to make them work with MicroLogix 1000 (since the driver at the time just couldn't get proper information, possibly because of ENI module).

Aabeck has nothing to loose by trying to set the type of processor to either &H5B or &H6F depending of what type of 5/04 he is using. If that doesn't improve the performance then he can always comment it out again.

[AabeckControls]

Godra,

The 5/04 in the machine is a 1747-L543C, the 5/04 copy on my desk for development is a -L543 (Not C). Which of the two hex numbers should I use for each or the same number?

I want to test this fully, then change the number if needed for the install.

EDIT: I asked before I opened the code in VS, there was a list of hex numbers for each processor. The 5/04 (except -L541) is &H5B. set it to that & removed the comment. It  should be the same for both PLC's.

EDIT2: Just tried it  & it does make a difference, also in DF1 changed the Baud from Auto to 19200, so it doesn't take time to try the other baud rates before starting comm's.

RE-EDIT: To make the Controls page load a little faster I removed 7 green Start PB's, added the Click bits from them to the 7 Pilot Lights & moved the Pilot Lights to where the PB's were.

Also, by a suggestion in a PM I got, for liability all the E-Stops were renamed All-Stop, and I deleted the two directory forms & put all FormChangeButtons on MainForm & on most other forms (except the button that would call the form on presently).