Messages

1

Tips & Tricks / Re: Using C#

« on: November 18, 2016, 12:11:24 PM »

Simple. You set up your development machine like this:

MyProject\AdvancedHMI

then you commit your project to your source code control system. Now anyone can pull that code from the repo, build, and they will get the same output files on any machine and can deploy to the target machine in the same manner. Need to make a change? Pull from repo, build new exe and xcopy to target.

I know it is common to have your complete build environment on the target machine but this may not always be feasible, possible, etc. I work in the highly regulated medical device industry and if you had the build tools and source codes on your target machine, where anyone could walk up and make changes to a validated piece of production equipment, that could get you shut down.

Same thing if the target machine dies, you need to have documentation on how to reproduce the system.

See: http://advancedhmi.com/forum/index.php?topic=1402.msg7606#msg7606

In short:

The licensing also requires distribution of the complete solution source code to the end user.

In other words: if you don't distribute the full source code with your product, you are violating the license. They claim the reason for that is because if in the future an engineer wants to modify the program, they can immediately do so. I proposed that that article of the license be reviewed and maybe changed to something like "must give credit". But it is ultimately the author's choice and we must respect that - he is the one that put in all the hours to develop this project and decided to open source it!

2

Open Discussion / Re: Source code for MfgControl.AdvancedHMI.Drivers.dll

« on: August 23, 2016, 11:11:42 AM »

As far as I know, this part of the project is closed source and undocumented. File a bug. The authors are pretty quick to release new versions with bug fixes.

3

Open Discussion / Re: Documentation

« on: August 23, 2016, 11:09:53 AM »

I have a proposal.
Some of us could post some articles and build a sort of manual under Archies supervision.
In first place must have an table of contents.
IMO it can be build and storage in sourcefourge in a directory.

That is a good idea

4

Support Questions / Re: Drivers depend on Controls?

« on: August 22, 2016, 02:42:26 PM »

The reason for this requirement is so the next guy to edit the solution has all the same controls available even if they are not used in the current revision. The next person may want to add more to the project and if his Toolbox is nearly empty , his first impression of AdvancedHMI would not be very good.

I see your point and I understand how it relates to HMI applications. It is a good thing that the next developer will have all controls available for them in the toolbox, and for sure will have a good impression of AdvancedHMI (Self-proliferating Marketing Model). However, I am not working on a HMI application. If the developer after me decides to improve my program, they would probably not care about UI controls in the toolbox.

My opinion is that item number 5 could be replaced by a "must give credit" clause. Say "somewhere in the developed application there must be a visible reference to AdvancedHMI and a link to advancedhmi.com". That way, whoever has to maintain AdvancedHMI programs in the future will have the information they need to find resources online and get to know the project. I think that this would be much more valuable, as it would motivate the following maintainer to update to the newest release (bug fixes + new features) and expose them to the non-free UI controls.

Additionally, it would expose non-developers to AdvancedHMI as well.

As I said before:

I won't deploy without giving full credit and I don't mind adding the rest of the DLLs as well as the project code to my program. I just didn't see any technical reason for that, that is why I asked.

5

Support Questions / Re: Drivers depend on Controls?

« on: August 22, 2016, 02:01:49 PM »

It is what it is. Respect what he ask.
I saw some youtube videos out there without crediting Archie's work. I politely asked them to include AHMI logo in there.

I won't deploy without giving full credit and I don't mind adding the rest of the DLLs as well as the project code to my program. I just didn't see any technical reason for that, that is why I asked.

6

Support Questions / Re: Drivers depend on Controls?

« on: August 22, 2016, 11:33:33 AM »

Thank you for the information. I also saw the note on UsageAndLicense.txt. I have to say that I fail to see the reason behind item #5:

5) AdvancedHMI must be distributed in full. You cannot remove parts or use pieces in another project

If full credit is given, I don't understand why the user has to ship unused parts of AdvancedHMI with their project. I do agree with all other items, and I do appreciate that the authors decided to use GPL!

7

Support Questions / Drivers depend on Controls?

« on: August 03, 2016, 01:28:33 PM »

Hello all,

I am working on an application that uses the communication drivers that AdvancedHMI provides, but not the GUI. However, I noticed that I must include all the following DLLs to have a working console application that does nothing but communicate with a ControlLogix controller:

AdvancedHMIControls.dll
MfgControl.AdvancedHMI.Controls.dll
MfgControl.AdvancedHMI.Drivers.dll (this is the only DLL that the application actually uses)

Interestingly enough, it works just fine with only the last DLL when the application runs from inside Visual Studio's hosting process ("debug mode"). So I am curious as to why this is happening. I noticed that the controls dlls are not present in the bin folder of the AdvancedHMIdrivers project, which indicates that there is no actual dependency.

Ideally, I would like to deploy my application with nothing but MfgControl.AdvancedHMI.Drivers.dll. I am aware that this kind of complaint sounds ridiculous when the whole AdvancedHMI is free to use, but MfgControl.AdvancedHMI.Controls.dll alone adds 6.2 MB to the final release! It would be great if I didn't have to ship it with the application.

I am using AdvancedHMI v399n. That you all for your help,

Leo

8

Support Questions / Re: EthernetIPforCLX Subscribe vs Read and best practices

« on: July 27, 2016, 06:30:06 PM »

Yes, it is an outgoing limit. If an incoming packet exceeds the limit, the PLC will break it up and the driver will reassemble it.

Perfect. Thank you!

9

Support Questions / Re: Subscribe Function Event Triggering

« on: July 27, 2016, 02:37:07 PM »

That answers all my questions. Thank you again Archie, great work!

10

Support Questions / Re: EthernetIPforCLX Subscribe vs Read and best practices

« on: July 27, 2016, 02:29:39 PM »

You can read groups of random tags as long as the header length + tag name lengths + a few other support data does not exceed 508 bytes. The subscription systems final read is done using the BeginReadMultiple function.

Great! Thanks Archie!

So the 508 bytes maximum is for outgoing or incoming packets?

11

Support Questions / Re: EthernetIPforCLX Subscribe vs Read and best practices

« on: July 27, 2016, 02:27:04 PM »

You can use and specify separate callbacks for each subscription. This is an example if using the Modbus driver:

So that is pretty much what I tried to do. The three main differences are
1. I am using C#
2. It is a console application
3. I was using the same callback function for the three tags I subscribed to
4. I am using the MfgControl.AdvancedHMI.Drivers library
5. I am also using the SubscriptionDataReceived event

Here is the code: I noticed that On1 was never called, but On2 was called every time (once for each combination of transaction and subscription)

Code: [Select]

        private static int id1 = 0;
        private static int id2 = 0;
        private static int id3 = 0;
        private static EthernetIPforCLX b = new EthernetIPforCLX();

        static void Main(string[] args)
        {
            b.IPAddress = "192.168.1.220";
            b.ProcessorSlot = 0;

            var t = 500;

            b.PollRateOverride = t;
            id1 = b.Subscribe("TestNum1", 1, t, new EventHandler<PlcComEventArgs>(Program.On1));
            id2 = b.Subscribe("TestNum2", 1, t, new EventHandler<PlcComEventArgs>(Program.On1));
            id3 = b.Subscribe("TestNum3", 1, t, new EventHandler<PlcComEventArgs>(Program.On1));
            b.SubscriptionDataReceived += On2;

            ...
        }


12

Support Questions / Re: EthernetIPforCLX Subscribe vs Read and best practices

« on: July 27, 2016, 01:16:32 PM »

Yes, the BeginReadMultiple does combine multiple requests into a single packet. However caution must be exercised because it does not valid the length of the packet. Once too many tags are packed into a single BeginReadMultiple, it will just stop working. The total packet length is determined by the CIPConnectionSize property of  the driver, which is 508 bytes by default.

Thank you!

So does that mean I can read up to 508 bytes of randomly-positioned memory or does it have to be 508 bytes of sequential memory? Other than not validating the packet size, does it have all the capabilities that the subscription system has, as far as driver optimizations go?

13

Support Questions / Re: Subscribe Function Event Triggering

« on: July 27, 2016, 01:06:58 PM »

If the driver decides not to group reads, would it return different TransactionIDs for tags that were captured at the same "time"?

I put time in quotes because I understand that there would be two or more different packets. But from a subscription standpoint, the values belong to the same point in time.

Would you recommend ignoring the TransactionId and using solely the order of arrival to record the data? Is there any parameter I can change to prevent the driver from sending the next request without having received the previous response? I would rather have it fail on a timeout than receive data out of order.

14

Support Questions / Re: Subscribe Function Event Triggering

« on: July 27, 2016, 11:32:30 AM »

Would this be a little more efficient?

Code: [Select]

if (e.SubscriptionId == myId)
{
}

Because the communication driver optimizes reads and combines them into a single packet, can I assume that e.TransactionId will be ordered?

15

Support Questions / Re: EthernetIPforCLX Subscribe vs Read and best practices

« on: July 27, 2016, 11:27:20 AM »

Thank you for your reply.

I can get subscriptions to work with the event SubscriptionDataReceived, but then I get all the callbacks in one place rather than being able to use different functions for different read subscriptions. It is working fine though.

Yes, I noticed that the driver is indeed very efficient - I have observed that 5 ms average myself. Very impressive! And I will not try to reinvent the wheel, I will just write some glue code to use the current subscription system.

I am not sure of what I should do to have different poll rates for different tags. I see your point and I agree that there is a tricky balance to it. For now I think I prefer the idea of using different drivers. Will the drivers optimize their packet size for just the tags that I want or do you think I would be creating overlaps? I don't want to read data just to throw it away, and I wouldn't like to read duplicate data either.

On a separate question: does the BeginReadMultiple method combine requests into a single packet as well?

Leo