Saragani

Hi, your code is right, either using Write or Update will update the content on the PLC. However, what about updating the cells values on the PC? You are using reloadCellsData to load the cells data into the UI (Probably a grid)... Are you sure that editing the UI makes the changes back to the cells in the Data Tables DLL? (Maybe you are just changing the UI?)

You need to create a new compiling profile (Just like the x86 and x64) that will be called Any CPU You can also compile your code as x86. This will also cause your code to work (although it is not recommended).

Please send the project to Unitronics support

Hi, the Sourcecode / DLL might be compiled as 32Bit and your program as "Any CPU" which might cause problems, so please check that both of them are compiled to the same CPU type (Any CPU is usually the best) Without seeing your project I can't actually guess what the problem can be. Can you post a screenshot?

What OS are you working with on your PC? (Windows XP, Vista, 7?) Is it 32 Bit or 64 Bit?

Hi, I now understand what you want... I thought that Visilogic and the PLC does not preserve the sign in Shift Right... Actually, Visilogic is acting as it should... Shift right is like dividing by 2. Lets start with the fact that 8000h is not equal 32768. 8000h (of 0x8000 as some people write) is -32786, so the result of dividing it by 8192 gives the result -4, which is 0xFFFC Shift right would gave the same result. So as some people proposed, you need to put the number 0x8000 to a ML, so the MSB won't be 1.

Hi, You can achieve the result you want by dividing the original value by 8192 (2^13) It seems that the Shift Right does not preserve sign.

Try using the designer version that matches the release date that Visilogic 7 was released. You can also send the VDF file to Unitronics support...

Hi Deke, which model of V570 you have?

If PC is Ethernet Master (The PLC is in Listen Mode) then: 1) Each Ethernet class corresponds to a socket. The socket is being created only after you are trying to establish a connection. 2) When you get a PLC Object then the socket should be opened. 3) If socket is being closed for some reason, when trying to communicate with the PLC again, the PLC object will try to reopen the socket and communicate with the PLC. 4) if socket could not be opened or communication failed, you will get ab exception. 5) Since each of the PLCs has a different IP address, you will need to declare an ethernet channel for each of them.

Please read carefully what he wrote: There I specify the Same IP addres Protocol TCP and Port Number 20256 and PLC Name the serial number. JE4500785 JE4500785 isn't a legal PLC name. This is why he can't establish a connection. To get the PLC name, you can enter the Info mode, and click on "Version". You should see the PLC Name. You can also use a serial cable to read SDW 9. When PLC name is not set by Ladder, the default PLC Name is the value of SDW 9.

Have you checked connectivity with Remote Operator or SD Card Explorer (or any other of our .Net based applications)?

Yes, use SD Card Suite. It has a program called SD Card Manager...

Ok, I'm glad to hear that it solved your problem :-)

Hi, here is a .Net 4.0 compiled version of Remote Operator 1.0.23. Please uninstall your current version first and only then install the new version!!! Please keep me posted if it worked or not. Thanks Remote Operator Version 1.0.23 - .Net 4.0 Compiled.zip

Hi, I can verify that it is a problem with .Net 3.5 or with the Bluetooth driver. See here: http://social.msdn.microsoft.com/Forums/en-US/Vsexpressinstall/thread/440c79b8-2f55-4d1b-a4e8-df931f3d7fa9/ and http://connect.microsoft.com/VisualStudio/feedback/details/236183/system-io-ports-serialport-getportnames-error-with-bluetooth You can try updating your Bluetooth drivers (Maybe it will work).... Btw, Changing the Regional settings will not help you in this case cause the problem is reading values from the registry. (Normal serial ports strings end with a Null while Bluetooth strings don't, so an extra character is being read from the registry binary file). I now understand why regular ports works fine (Because this bug only appears in BlueTooth ports).

Hi, I saw it. The previous version of the exe I have you was compiled using .Net 4.0 and the current version is compiled using .Net 3.5 In the first version, the port names returned by your system where like COM1, COM2, .... With the new version it is like: COM1?, COM2?, ... (An extra "?" is being added in the end of the string). This implies that the problem is not with Remote Operator itself but with .Net 3.5 (It probably has a bug related to 64 Bit os and/or non-English systems). You can try changing your regional settings to English. It might solve the problem. Beside that... I assume that you cannot even connect using Serial Cable and Remote Operator on Window 7 x64 since it should fail on the same reason. Am I correct? Please note that I need to compile a new version of Remote Operator and all of it's dependencies in .Net 4.0 so it might take a while. I will also search the Internet for the specific problem where .Net 3.5 fails to get the correct serial port names from the OS. Thanks again for your feadback. Btw, If you do try changing your regional settings then please update me if it worked or not.

Hi, I think that the message was not emailed by PMed to you (Check your private messages on the top right corner). Sorry...

Hi, I have sent you an email with a small program in it. Use this program to get all port names. Please also provide me which port are you trying to use (COM1, COM2, COM3.... etc) in order to connect in Remote Access and Remote Operator. Thanks

Hi, do you have a Visual Studio in your computer? I'm wondering if you can run the following code and tell me it's result: string[] portNames = SerialPort.GetPortNames(); foreach (string portName in portNames) { System.Diagnostics.Debug.Print(portName); Colsole.WriteLine(portName); } SerialPort requires: using System.IO; If you won't have Visual Studio then tell me and I'll code a small Exe for you that will show those results. 10x

Ok, our support says that they helped another customer who encountered a similar problem with Windows 7, BlueTooth and one of our .Net based applications (Like Remote Operator). They say that turning the UAC off and Unsetting the c:\Program Files (x86)\Unitronics\ readonly option (Make if from ReadOnly to non-readonly) solved the problem. Please note that after turning off the UAC, you must restart your computer.

I'll ask our support it they can simulate this problem. It is indeed very weird...

Please ignore whatever someone told you about reading files from SD. It is possible to read files from the SD using the .Net communication driver fairly easy. The PLC class that you probably familiar with, has a sub-class named SD. Inside it you will see some functions for reading, writing and Listing the content of the SD. Also see my Blog Entry So... you wanna build your own SD Card Explorer?!: http://forum.unitronics.com/index.php?/blog/3/entry-20-so-you-wanna-build-your-own-sd-card-explorer/ Reading the file from the SD should be easy. What you are going to do with it may be harder. If the file is a UDT or FDT file, then you can use the Unitronics.DataTables.DLL in order to open the file. Please use the most recent version of the DLL combined with the most recent .Net communication driver that can be found inside the SD Card Suite!!! If you need to read and understant UTR, ULG and Alarms files, then you will not have an easy way of doing it.

No, visiligic can accept only 1 connection. (How would you show the Operands values and HMI display of remote access when several PLCs connect to Visilogic?). The new Download Manager also doesn't support Listeners since it problematic. When you use the Downloader you tell it "I want that application on that PLC (by a givien communication settings)". When having several PLCs connected to the same Port, how would you know which application should be downloaded to which PLC? There are several other issues regarding this concept.

Hi, Does Visilogic manage to communicate with your PLC? If only your program fails, then you should check that the checksum in your program is calculated right and that the request you have sent is legal. If you enter the INFO in your V570 --> Ethernet --> Monitor --> Choose the right port (0 to 3, depends on the port on the PLC you are using), you can see the Tx and Rx buffers. In the Rx you should see the message that the PC sent to the PLC. You can choose to see the buffers in either HEX or ASCII. The Monitor shows the message after stripping the "Ethernet Header". In case of a Binary Protocol, you should see that the message sent from the PC starts with /_OPLC If you see that there is data in the Rx buffer, but nothing in the Tx then it means that either your checksums are wrong, or something else in your message is wrong. If you don't see anything in the Rx buffer then it means that your PLC does not receive the message and it is therefore a problem with the communication settings in the PLC (Socket is used, IP address changed, port changed, protocol changed, Master/Slave changed). Please keep me posted about the progress of finding the problem. I'm not from Unitronics support but actually from their R&D so I'm not always available to help and answers questions, but I do my best. So if you have any technical question about the communication protocol, you can always forward it to the R&D through out great support. I hope it helps. Thank you, and have a nice day.