Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - seth350

Pages: 1 [2] 3 4
16
Additional Components / Re: Mono Serial Drivers - DF1 and ModbusRTU
« on: January 25, 2018, 09:48:57 PM »
Thank for the contribution. I too use AHMI on a Raspberry Pi w/ Mono and know first hand how it can be temperamental.
Are you planning to do any work with the CLGX Ethernet driver? I ask because you mentioned high cpu usage. I also experience that with my app using Ethernet driver. The app will truck along at 4% cpu for a good amount of time, then for some reason go up to 60% and after some time go to 100%.


17
Additional Components / Re: TCP Client Socket
« on: January 25, 2018, 09:35:41 PM »
Now this is something I could use. Thank you Archie!
I need to send a String to a Domino DSeries laser marker and I think this will do the trick.

Definitely easier to do it in AHMI than in the plc, in my case that is.

18
Open Discussion / Re: Custom Component Debugging
« on: January 25, 2018, 09:22:08 PM »
I did get it working. However I scrapped using the Cognex SDK and just handled the scanner comms in the PLC. A lot cleaner and simpler.
One thing the SDK does not address is wireless scanners going into hibernation and losing connectivity. It would require the app to be restarted or call the disconnect sub and then the connect sub.

What I have is just a component built from the SDK that includes some properties to allow you to set the scanner IP address and also pick a label on your form to where the scanned string would show.

It wasn’t very difficult and would just require you to download the SDK and then reference it in your project.

Then add this at the top of your code.
Imports Cognex.Dataman.SDK

There are other things naturally that need to be set and the SDK includes a sample project that shows the code and how to set it up.

I can help when I can. I just have other things going on too.

19
Application Showcase / Re: Bar Code Verification App
« on: January 16, 2018, 02:37:03 PM »
Thank you guys for the feedback.

Do you have the part # of Prosoft Wifi Radio?

Sure do. I used this guy here. RLX2-IHNF-A

Supports b/g/n

I've done tons of custom applications with the Cognex Vision products. I use their SDK's all the time for applications. 

I initially started that way and did achieve the same result. However I could not figure out how to handle the WiFi barcode scanner going into Sleep mode. This would close the tcp socket on the scanner side but leave the socket open on the .net app side. Even after the scanner came back online, the socket would still receive the scanned data, but the SDK would just ignore it. Rebooting the .NET app would get everything talking once again.

I finally gave up on that path and stuck the Compactlogix in to handle the connections to the scanners. I think it will be easier to manage and troubleshoot a problem using the PLC than in some tcp socket code, for me anyways.

The Cognex scanners also support Javascript, so you could *i assume* create an entire application that is housed only in the scanner.


20
Application Showcase / Re: Bar Code Verification App
« on: January 08, 2018, 09:17:07 AM »
Nice application! Out of curiosity, why did you use the Raspberry Pi instead of a Windows PC?

Thank you, Archie. I appreciate it. The RaspberryPi was already approved through IT to be used on the production floor. If I had installed a Windows PC, it would then need to have went through an auditing process and then setup to receive automatic updates and security patches. Not the best scenario for something that will need required restarts and running production.

Simply just chose the lesser of two evils. If the Windows PC didn't have all of the extra chutes and ladders, I would have used it.

 

21
Application Showcase / Bar Code Verification App
« on: January 07, 2018, 11:38:11 PM »
I don’t usually post my work but I would like to hear others thoughts. Feedback welcome.

My company wanted a system to verify that we are using  the correct components during assembly.
I managed to do this using the following:

AdvancedHMI running on RaspberryPi3 with Mono
Compactlogix PLC
Cognex 8050 WiFi scanner
Prosoft WiFi Radio (serves as hotspot for the raspberries)
SQL Server 2014

I tried to make this app as portable as possible. All stations are running the same exact app with an ini file for its settings. Running three stations at the moment. Each station is configurable using bits from the PLC to bypass or enable scanning of certain components at each station. We needed the ability to change where certain components get scanned during assembly. In the case of an absence or special case scenario.

The PLC is also used to connect to the scanners and relays the scanned data from the respective scanner to that scanners respective station. The SQL lookups are done in AHMI. I initially tried to use Factorytalk Transaction Manager, but AHMI was faster in getting the SQL data.

The jist of operation works as follows:
An operator must first scan a SKU or UPC Number to see what they should be scanning. AHMI receives the scanned code from the PLC and then determines if they scanned a SKU or a UPC. If valid, AHMI then requests the BOM from SQL using WHERE SKU/UPC=‘scan’. If data is received, AHMI creates a new data table and stuffs the received BOM into it. It will then send the BOM to a Station UDT in the PLC for retaining the data. AHMI will then check which components are enabled to be scanned and then build the listview with just those parts.
The operator can then start scanning their components to verify they are correct for the SKU/UPC being assembled.
As the operator scans each component, AHMI will verify the scan matches one in the listview and check off and highlight the row that was scanned. It will also determine if a component has already been scanned. The status area gives the operator information as to what effect their last scan had.
Once all components are scanned, AHMI will alert the operator and then clear all data from the listview and labels.

Wish list:
Ability to use more than one scanner per station. (Haven’t figured this out yet)
Use something other than Linux to run AHMI. Porting to Mono is full of gotchas.
Station performance metrics



22
Support Questions / Re: Problem connecting to PLC5/30 DHRIO
« on: October 13, 2017, 11:15:02 AM »

23
Support Questions / Problem connecting to PLC5/30 DHRIO
« on: October 13, 2017, 10:04:23 AM »
Ive got a ENBT-DHRIO in a contrologix rack that is giving us access to a DH+ network over ethernet.
Theres a SLC and two PLC5/30s on the DH+.

Using the PLC5toDHRIO driver, I am only able to connect to one of the PLC5s and not the other. One is at Node 4 and the other at Node 50.
I am able to go online with both PLC5s over ethernet as well. RsLinx is seeing both of them and can also monitor tags from Linx.

I have looked at the channel config of both PLC5s and the only difference is the baud rate on channel 0.

Driver settings:

CIP Connection Size: 258
DHRIO Slot: 0
PollRate: 500
Port: 44818
RoutePath:
Timeout: 5000

DHRIO Channel: A
Disable Subscriptions: False
IniFileName:
IniFileSection:
Max PCCC Packet Size: 236
Target DHPlus Node: 50

It does generate an exception on startup "Read Failed - 2. Unknown Message - 2"

Wireshark shows the handshake between my pc and the ENBT adapter. Then they begin transmitting "Implicit Data - Class (0xa6)" No visible errors. The wireshark for the working PLC5 doesnt appear any different.

Any ideas?

24
Support Questions / Re: Windows 10 IOT Enterprise
« on: August 21, 2017, 08:19:45 PM »
Well then that is good news  ;)

25
Support Questions / Re: Windows 10 IOT Enterprise
« on: August 21, 2017, 10:05:40 AM »
From what I have read about W10IoT is that it will not run Windows Forms apps. It is geared towards the UWP which is totally different than Forms. So much that a forms app cannot be directly converted to a UWP app. There is a UWP desktop bridge that allows developers to migrate their forms apps to UWP while still supporting their legacy clients (Non Windows10/8.1). Although, it just allows a developer to slowly convert their current app to UWP.


26
Support Questions / Re: App freezing when showing windows forms.
« on: August 02, 2017, 11:34:34 PM »
When you created these new forms, did you copy the first two methods from the top of the original main form to all other new ones? And are you using the formchange button provided with AdvancedHMI to open your additional forms?


27
Open Discussion / Re: Memphis, TN area users?
« on: August 02, 2017, 11:29:59 PM »
I'm two hours north of Memphis. What products will be presented?

28
Open Discussion / Re: Where do we draw the line?
« on: July 26, 2017, 11:17:12 PM »
Good point about already developed tools.
What is interesting is that at first, in my project, the plc was the central control. As I slowly went down the rabbit hole in transferring control entirely to aHMI. While it does work, I am finding out that there is a cost or rather trade offs/cons in doing so.
For instance, due to the nature of tcp protocol, if a scanner is disconnected and then reconnected, the app no longer recognizes that the scanner has scanned something. I must disconnect and then reconnect. From my understanding, this is because a port was left open and the client does not realize that there is no longer a server to listen to. Typically if this were connected to a PLC, you would get an "I/O Not Responding" and once the server reconnects all is well again.

Needless to say, version 2 of my app will include the plc once again so that I will gain back the "already developed" features. Some might say, "just disconnect programattically and reconnect". Not that simple if your app has methods running in separate threads.

I suppose my real reason for creating this post was so that new comers would be informed and not go down the same rabbit hole as I have.


29
Open Discussion / Re: Where do we draw the line?
« on: July 21, 2017, 10:23:24 AM »
Your right, scan time or shall we say the ability to update an I/O in the least amount of time. We could draw a line there.

What about the all popular statement, "the pc is too hard to troubleshoot" or "the maintenance guys can't troubleshoot it/fix it", "KISS"

Could we draw a line at ease of repair? Or simplicity?

So maybe at the end of the day, you wouldn't draw one line, but many. In some cases, you could say that each line drawn would actually section off responsibility to who should worry about repairing it.

Sprungmonkey, that is also some valid points.

BTW, this is just an open discussion.

30
Open Discussion / Where do we draw the line?
« on: July 20, 2017, 11:21:21 PM »
Hey there,
So I have been developing a bar code/bom lookup using advanced hmi and some cognex bar code scanners. This project started out using a PLC, with aHMI being just just an HMI. Database transactions were being made through Factorytalk Transaction Manager.
That was a month or two ago...
Today, the PLC is no longer in the picture and neither is Transaction Manager. Everything is done in aHMI. Which made me wonder...where is the line drawn between controling a machine/process/whatever with aHMI or with a PLC?

Both can do much of the same, if not more than the other or easier than the other.

Where do you draw the line?



Pages: 1 [2] 3 4