Inverting LED in VB application

[Vorbis 1]

Hi, i'm programming an Interface for a PLC with Visual Basic and the ActiveX plugin from CX-Server Lite. I now would need an LED that is ON when the referenced Bit in the PLC is "0". Do I need to change the ladder program so that the bit has the right value or does anyone have a clue on how to invert this Bitlamp in VB? -Vorbis

[Berti Baker 7]

Hi, Yes you can reverse the state in VB code using the NOT operator e.g. LED1.Value = NOT PointValue However, when to run this code? Best (most efficient) could be subscribing using GetData command, and putting this code in the "OnData" routine to repond directly too every new value. For an expert PLC Programmer though you might just find the ladder option quicker. BB

[Vorbis 1]

I am veering away from using the Omron elements anyway. I prefer using standard VB elements and manipulate them with a timer and the AxComms.read() function.

[Berti Baker 7]

Hi Vorbis, This is OK for small applications but be carefull how is scales up. Having too many Windows Timers will cause efficiency/performance problems, and handling all the Read commands yourself means communications messages cannot be optimised. (i.e. nearby addresses all read in 1 message). Using .GetData is a compromise that solves both these. If you subscribe with the same update rate then Lite only uses 1 Windows Timer. And because the communications are all managed then CX-Server can join requests for nearby addresses. You don't have to use the Graphical controls - e.g. if you can find a good lamp photo you could make it visible/invisible or set the colour of a circle etc. Regards, Bertie.

[Vorbis 1]

Hi Bertie, seems like you know a lot about programming for CX-Server, I just started to play around a little. I noticed that my programm gets slower and slower with every Data request I send to the PLCs. I'm programming a monitoring software for two PLCs (might be more PLCs in the future). At the moment I have a main window that shows an overview of the most relevant Data of the two PLCs plus a detailed form for each. It's all done with timers, I have one timer in each form except one form has two of them. I got to notice that sometimes a form wouldn't update data somehow. Maybe using up to 4 timers when all forms are open isn't very efficient. What would you suggest? Making one timer in the main form and declaring them as public? Or should I just change all the labels to bitlamps and other Omron elements? Regards, Vorbis

[Berti Baker 7]

Hi Vorbis, Flatery will get you everywhere Yes I'd love to help and get you a good application. With the right design you should be able to get good comms e.g. 900 updates a second from a CJ1 over Toolbus is perfectly possible - I suspect a great deal more than you're seeing now !! My advice (for you to take or leave ) is to use ZERO timers. Read up on the GetData function and OnData event - even try a little sample seperately. You'll find that you can call GetData in your app or page initialisation script once to start ALL your regular reads. You can use a long switch statement in the OnData to handle every new data value received. Try it with as many points as you currently have, or double that to prove it is quicker. Take a look at the CX-Server bandwidth usage (Start->Programs->Omron->CX-Server->Performance Monitor) with your timer app, compared to the GetData app. But why is this better? 1) Firstly I know there are a lot of reliability problems with timers in Excel - maybe applies to VB too but not sure. 2) It uses less memory and CPU. Every time you call a single read, a whole string of events kicks of to create the objects and messages for communication, but at the end of their single use they are deleted. This memory allocation is exhausting and when called in succession is just a waste. By contrast ReadData reuses the same objects and memory for every message sent out. 3) Most important of all, GetData is the ONLY way that CX-Server can then optimise the communications. If you get data at the SAME RATE from nearby addresses it can get them in the same message. E.g for Ethernet it can read up to 1000 addresses all at a time. So reading 1 address or reading 1000 contiguous addresses takes the same time. This seems incredible but actually the tranmission time is negligible compared to the plc processing time. They say this is like a journey from London to Manchester - doesn't really matter if you take a motorbike or a lorry but you'll carry a lot more in the lorry!! CX-Server 'concatenates' these GetData requests automatically. All you have to do is ask it nicely rather than GIVEME, GIVEME, GIVEME !! Hope this insight encourages you to try it out - answers and help available if you need it Regards, BB