Saragani

It is done this way because a PLC object is an object that already has an active connection and that already established a conversation with the PLC. What do you need from the PLC object? (Why to you need to subclass it)? Maybe there is an easier solution for what you are trying to do. Maybe the thing that you want to implement can be added as a feature to the communication driver (if it's usefull).

Hi, How big is your DT? (How many tables. Do you know the total size of the Data Tables including Data on flash?) using the way mentioned on the documentation, you probably read specific data (specific rows, or specific cells)... Now you are requesting to read the whole thing which in your case, might be big. You can get only the structure (which you say it is fast for you), and then read the data of specific cells. Your DataTables object contains a list of tables where you can access by either index or key, for example tables[0] You can request Read/Write on specific cells: tables[0].Read(.......... Then iterate the cells that you read in order to get it's values

Hi, the Com enum was for easy configuration. However, when it was created, we allowed only up to 48 ports, and we have increased the num of ports to 256 only recently. Since you have the code, then you can easily change it so it will not work with enum but with a ushort. This way you will be able to enter the port number as a number up to 65535 and when needed create a serial port with port-name = "COM" + portnumber

Please see: http://support.microsoft.com/kb/100111 http://digital.ni.com/public.nsf/allkb/F7A9002D7B8E31E7862568D6006BD10B Windows (at least up to Windows XP) is limited up to 256... I'm not sure though about Windows Vista and 7, but the communication driver is build for maximum compatibility. About not being able to communicate with the PLC while using COM117, Please check the cables and confirm that both the PLC is connected to COM117 and that the program is trying to open the connection on COM117. If you are still not able to trace the problem, there are ways to sniff or log the communication in order to see what's the problem. Please confirm that your .Net program works when you try to work with for example COM1 or COM17 before starting to check it with COM117.

Depends on your PLC model. V2xx and V120 have a buffer size of like 480 bytes. V570/130/350/1210/1040 have a buffer size of like 960 bytes. In ASCII protocol ML consumes 8 chars, meaning, you can probably read something like 100-120 MLs in ASCII protocol on V570 (some chars are also taken on header and footer of the ASCII protocol). GPRS modems reduces the buffer size to like 128-150 bytes. CANBus also reduces the buffer size.

Hi, I would gladly take a look at your code on my spare time. Maybe I can find the problem.

If you don't get any problems then yes. Remote Operator writes files to the Remote Operator folder and sub folders and if it's set to have read/write/execute rights for everyone, then it will probably work ok.

Hi, Both Visilogic and Remote Operator require the UAC to be lowered to the minimum level settings. Both programs extracts or create temp files while working. You might not notice problems with Visilogic while working with it in recommended level settings, but it might fails when trying to open project on specific folders, create URC files for Remote Access or remote Operator, change INI files etc. Remote Operator will probably fail when trying to extract PLC models configuration to your hard-drive. Can I ask why are you tend to use the recommended UAC settings?

Hi, this is a problem with permissions. Make sure that the Remote Operator directory has a full permission (for the user called EVERYONE if such user is not defined for that folder, then add it to the folder)

OK, so the .Net program was never tested on Windows XP, so you can't be sure if the locks also happens there. I do see that serialgear is also using prolific chips (and I hope the FTDI is not using the same driver as prolofic. My guess would be not). Can you run the .Net program on XP and see if it also locks? Can you test other .Net programs like Remote Operator on windows 7 and see if it also locks? Can you have the .Net program connect to the PLCs using Ethernet, instead of Serial port connection? The ActiveX communication driver is single threaded without locks and with DoEvents (to prevent UI thread from locked and UI from not responding). The .Net driver is Multi-Threaded, can work with several PLCs at the same time (while managing messages queue) and have locks to prevent threads from changing data which is commonly used by them (For example, 2 threads enqueuing or dequeuing messages from the queue. Without the locks, there would be exceptions). I can't really suggest a solution or see why it fails without seeing the code. I hope that running Remote Operator (while connected to both PLCs) would not lock, cause it will then will suggest that the fault is with the program (which is easier to debug, other than the communication driver).

Hi, first try to see if other Unitronics .Net based programs lock on Windows 7 64 Bit.... For example SD Card Explorer or Remote Operator. If they doesn't lock then it might suggest a some kind of a fault in your program that causes a dead-lock in the Communication Driver. You did not mention what kind of connection you use: Ethernet, Serial, Listener? If you do use Serial connection, is it a USB To Serial (with Prolific driver)? Sometimes the locks can happen inside the Communication Driver due to bad drivers (in the case of the Prolific USB to Serial). Any information you can supply might help.

Hi, I don't see any attached screen shot, but from what you are saying, you are getting the access denied when opening the communication settings dialog, which means that it is not because of communication problem. I believe that it is a message about access that is being denied to a file. (Either read/write/update). The first thing you can try is decrease the UAC settings to the minimum.

Yes and no.... Yes, if you are saving the trends into SD and then use the Communication driver to read the trends file... but you will then need to do something with the file (You need some program that will open that file, for example SD Card Suite that converts it to USD files and then shows it on the PC, or converts it to CSV or Excel). No, if you don't want to use any software in order to understand the trend file. No, if you want to read the currently running trend without saving it to an sd card (Remote Operator does it, but it has a lot of logic on understanding what it reads, and it also requires a trend HMI element).

It exists, but all its data is located on a different address and it doesn't consume space from the RAM data tables

I know that you can set the time you need to touch the screen in order to get into the Info (and as much as I recall, you can even disable it), so you can disable by this way also the access to the calibration. I don't remember any SB to SI that disables only the calibration (But I'm sure that our support knows better, and there are also documents about those SBs/SIs). Either way, I'm not sure that it is possible to block touch screen calibration or info only for remote users.

Prolific are known for their bad drivers. (I'm not sure who is worse, them or nVidia...) The driver seem to behave differently when working with VB6 and when working with .Net I remember that in some older versions the .Net would expose a serious bug they had with the FIFO (while in VB6 it worked correctly), and on a newer version the .Net driver worked fine, but with VB6 the program would hang since the Send command will sometimes caused an infinite loop (the CPU usage would go high and the program will not proceed after the Send). You might wanna try an older version of the driver. A topic from the old forum: http://www.unitronics.com/forum/topic.asp?TOPIC_ID=3097&SearchTerms=prolific Please give it a try and tell us if it works better.

I'm glad to hear that it works :-)

The C# code looks enough for getting a connection, but the PLC program is not even trying to establish a connection. Lets get over the code: Network 1: On PLC init, set PLC name and do a Card Init Network 2: On PLC Init, Do a card Init (why doing it again), and then do a socket init (It's OK, TCP Master). Network 3: Disabled Network 4: On F1 Key down, UDP Raw send some data Network 5: Disabled. No where in the PLC code you try to establish a TCP connection to the PC. The PC listens to TCP connections, so there is no use for sending UDP requests. The PC doesn't expect to get requests from the PLC, but on the other way around... the PC will send a request (using Unitronics standard PCOM) to the PLC (for example, reading MIs) and will get a reply from the PLC. I've attached a small PLC program. When you press F1, it will try to connect to 192.168.0.205 on port 20260 I hope that you will get a "connected" messagebox with that C# program. TCP.vlp

Hi, you need to set the socket to TCP Master (and have the ladder try to connect to the IP 192.168.0.205) and not ICMP. ICMP is used for ping and not for data transfer.

I didn't get any mail from the support yet. Hi, nothing should happen after the line you mentioned (the one that should execute the OnConnect) since it's an event. OnConnect will be executed when the PLC will try to establish a connection to your PC on that specific port that you listen to (make sure that firewall does not prevent that connection). I see that the OnConnect has some code on creating a connection through Ethernet. I don't think that you need it since you already have a connection to the PLC (you get a PLC object as a parameter of the OnConnection function). You can use that PLC object for reading and writing data from the PLC. Few things to check: 1) Check that the PLC actually tries to connect to the PC. 2) Check that the program in the Examples works for you (It manages to get connection and reads MIs etc). Btw, are you sure you need a Listener? Listener will make your PC wait for a connection request from a PLC. On the other hand, if you know the IP and the port of the PLC (and the PLC is listening using TCP, meaning it has a socket in TCP Slave mode) then the PC can establish a connection to it using Ethernet (instead of Ethernet Listener).

Yes, send it to Support@unitronics.com and request in the mail that it will be passed to Saragani from the R&D.

Ok, you have a lot of work to do on your C# syntax. 1) you have a static function called GetPLC which doesn't return anything. 2) That function is not written correctly (c# syntax), instead of having it's code surounded by { }, you have a ; at the end of the function definition. The code you meant should probably be something like this: public static void GetPLC() { The rest of your code here. } You can also have the EthernetListener sent as a parameter to that function (like you did), but then you will need to use it (instead of creating a new one, like you did).

What's the error you get in the compiler? Do you need a 1 connection listener, or a "server" that can handle multiple connections from multiple plcs?

I know that you can set a timeout for the socket (if a connection is opened and no data was sent for a while then the socket in the PLC is closed.

Hi, the UnCmDrv1.DLL uses mscomm32.ocx and for the ASCII protocol it sends text just like you do. Please confirm that all the communication configurations are matching (Baudrate, Stop Bit, Parity etc)...