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 - TravisB

Pages: [1] 2 3
1
Technical support / Re:Modbus TCP Slave problem
« on: April 23, 2013, 01:10:31 PM »
Sorry for the late reply BC, got tied up in some other details. My problem ended up originating from another system (other contractor) using the same IP and port as we were using. Once we changed the port number communication has been great. We're still a bit doubtfull, so I'm going to add code similar to what the REBOOT would have done.

I will increment the value of a DM field every second. When the SCADA connects it will read the counter, then zero the counter. Nice routine communication means the counter should get zeroed more than once a second. If there is an outage then the counter will keep increasing.

If the PLC DM field reaches one minute it will "make note" and could also REBOOT if that's what you need.

I will also add code to my SCADA that will "make note" if the DM value is greater than 15 seconds.

I havn't written the code yet, but that will be the strategy. If there is a more elegant solution I'd like to learn about it because I think this bit of code is a valuable addition and it will find it's way into future projects as well.

2
Technical support / Re:Modbus TCP Slave problem
« on: April 19, 2013, 05:44:40 AM »
When the PLC regains connection it's typically for less than an hour before dropping off again for longer than an hour.
Our setup is not using WiFi, it is hard wired, so we will proceed with the REBOOT option. I was saying I can't find any documentation explaining how to use REBOOT, even looking in the manual available for download on the TRi website.

3
Technical support / Re:Modbus TCP Slave problem
« on: April 18, 2013, 12:25:36 PM »
I also can't find any documentation for the REBOOT command. I think it is different than the REFRESH command, which I do have documentation for.

4
Technical support / Re:Modbus TCP Slave problem
« on: April 18, 2013, 11:49:14 AM »
We are having a similar problem to what BC Systems describes, with the exception that when the SCADA/MODBUS connection is lost we also loose the FServer connection. The other difference is that eventually the PLC communication returns for awhile, even without reset/reboot. Since we are remote, when we loose communication we cannot do anything but wait.

Is the solution the same? Do we build a REBOOT trigger into the code or should I start elsewhere?

System Description:
Single f1616-BA connected via Ethernet to onsite PC
SCADA software is hosted on that same PC, uses network to communicate with PLC.
We view the SCADA and PLC Online Monitoring on the onsite PC via Remote Desktop Connection to the onsite PC.

I'm not sure how to find the firmware version of the remote/onsite PLC.

5
Technical support / Re:Writting data to local PC
« on: January 07, 2013, 03:43:07 PM »
After having the PLC and PC communicate reliably on an hourly cycle for a few months, the PC died. The client rebuilt the PC but ever since the rebuild the success of the PRINT #4 command has been sporadic/rare. It appears that one part of my code reliably sends data, but it's only a daily command. My hourly PRINT works less often than once a week. To be clear, days when none of the hourly data get's "print"ed I still get the once a day "print" from lower in the same function!
I've cleaned up the code, added </> and </RemoteFS> all over the place and even restarted TLServer a few times but I'm still not seeing results. I see that I have two options, either try to fix the problem using the same method (PRINT #4) or try a different method for datalogging. The client is requesting 1-minute datalogging, so I'm ready to put the burden on something besides the PLC.
1) Secs, if you're still listening, could you tell me what software you use to pull data off the PLC?
2) Is my generous application of opening and closing <RemoteFS> contributing to the problem?

I was thinking about this overnight and wanted to mention that I have no problem monitoring the PLC, so I know the connection through TLServer is working.

6
Technical support / Re:Writting data to local PC
« on: August 20, 2012, 10:27:11 AM »
Wow secs, that looks great. I am already taxing my F1616 with all the tasks it is required to do, so I'm hesitant to push very much data through. I'm trying to talk the client into few data every hour and most data being sent/stored daily. (I'm also taxing my own brain just getting the basics working.)
At this end of this project I'd like to take everything I've learned at set up something similar for my home. It will be even more fun to work on this when I can do it /my/ way, and also without deadline.
I presently have the PRINT #4 command working, and we've decided we can do without storing decimal data, although I'm keeping in mind the suggestion that support gave for putting the print command inside the "IF"


7
Technical support / Re:Writting data to local PC
« on: August 10, 2012, 03:24:20 PM »
Thank you for the help, I've got some things working now. It seems that one "PRINT#4" starts a new line of printed text, so if you want several things on one line then keep adding them (with the +) and when you want to start a new line, do PRINT#4 again. I wan't able to get things to work and I believe the problem was I wasn't closing the RemoteFS. Once I got </RemoteFS> included in my code, several files from prior attempts showed up. I think they were out in computer limbo until released by the </> command.

 There are two things I havn't been able to figure out yet.
1) I can't get the PRINT#4 to work from within the "1stScan" function. I'm not sure why this is, and it's not a big problem as I've a workaround finished, but it would be nice to have the 1stScan put in the headers (first line of the file.)
Should the PRINT#4 work from 1stScan?

2) I can't format things exactly as I wish. I'd like to have the date,time, then data values all on the same line. The problem is to format the data values I need to run "If" statements to properly format decimal point data. The compiler seemed to prevent me from doing that.
Should the PRINT#4 work with IF statements?
example:
PRINT#4 "Text..."
 if A > B Then
  +A
 else
  +B
 endif
 if C > D Then
  +C
 else
  +D
 end if

PRINT#4 "End of File"

8
Technical support / Writting data to local PC
« on: August 08, 2012, 11:30:22 AM »
I see that ExcelLink is the easiest method to get data off a PLC and onto a PC, but requires Excel be on the PC. I don't want to us the Email method because, as I understand it, I'd end up with a new email every hour when really I want to appened to an existing file. I get the impression that there are other methods as well, but I don't understand the jargon to know which one (Modbus, Multi-point, Host Link Protocol) I should spend my time learning about. I've read those chapters and I will need to spend a lot of time on wikipedia and elsewhere learning what all those words mean before I can proceed.

I have an onsite PC connected to the f1616-ba PLC via ethernet cable. It is dedicated to runing several operations and is expected to be "On" at all times, running TLServer. I would like to have the PLC initiate communication and send many DM fields to a location on the PC. Hourly, and appending to an existing file.

Where should I be looking?

9
Technical support / Re:Memory after power down
« on: July 12, 2012, 11:01:11 AM »
Do the EEP commands work in the simulator? I've been trying and having no luck, so I think not, but I thought I'd ask just in case the mistake is mine.

10
Technical support / Re:Program execution takes longer than Clk:1.0 Clock?
« on: July 08, 2012, 02:28:47 PM »
Success from the field. The pull-up resistors are being powered by the DAC#4 of the AN20MA-2. The AN20MA wasn't wired to 24V power supply, so it wasn't getting power to the DACs. Once that mistake was discovered the 7017s were having 100% success rate of connection for the few hours it was being monitored.
Trouble-shooting rule #3, Check the wiring before blaming the "black box."

11
Technical support / Re:Program execution takes longer than Clk:1.0 Clock?
« on: July 05, 2012, 11:53:05 AM »
Quote from: support on July 05, 2012, 10:20:53 AM
Are the I-7017s and the PLC sharing the same power supply? If not did you connect their 0V together (it could be to the shield of the twisted pair cable)?
--No, the I-7017s are using different power supply units, same brand and model though. I hope we have an extra wire available for connecting the 0Vs. So on the AnalogGnd from the PLC (via AN20MA) to the (B)GND 10 on the I-7017.

Quote from: support on July 05, 2012, 10:20:53 AM
At 50 ft and 100 ft you shouldn't have so much difficulties communicating unless there is a setup or programming problem or there is a big noisy equipment that is coupling high energy noise pulses on the RS485 wire. Did you use a twisted pair wire?
--I will verify this.

Quote from: support on July 05, 2012, 10:20:53 AM
Since you have a U-485, you could take the PLC offline first and then use the software tools supplied by ICP-DAS to monitor the I-7017s on a PC and check if you have any difficulties communicating with the I-7017s.
--If connecting the common ground doesn't work, I'll move onto this step. Is it the DCON Utility (http://ftp.icpdas.com/pub/cd/8000cd/napdos/driver/dcon_utility/) that I want? (Here we go again with trying to learn new software to troubleshoot equipment that's installed in the field. :-\)

Quote from: support on July 05, 2012, 10:20:53 AM
If PC communicates well with the I-7017 then you can connect the PLC to the RS485 port (quit the ICP DAS software since you don't want the PC to interfere with the communication between the PLC and the I-7017s.

Also are you sending ASCII commands back to back to multiple I-7017? Try putting a small delay between two consecutive commands as the I-7017. You can try it with 1 second delay and see if it improves the response and if it does then slowly decrease the delay between two commands until you reached minimum delay necessary between two consecutive commands in order not to have disruption.
--I have a 5 second cycle with each 7017 being called on a different second (2, 3, and 4) resulting in less than a full second separation between calling. I can rework the program to add a longer delay if nothing else works.

Quote from: support on July 05, 2012, 10:20:53 AM
Regarding Realterm software - note that this is not our product and we only recommend it because some users have good experience with it, but we won't know their donation policy and we can't guarantee its performance in doing their job.
--I understand this is not your product. Maybe someone who has used it with success can help out here.

12
Technical support / Re:Program execution takes longer than Clk:1.0 Clock?
« on: July 04, 2012, 11:47:14 AM »
The equipment has moved out of the lab and into the field. Everything is wired up and it appears that I'm failing to communicate with the 7017s more often than not.

One 7017 is adjacent to the PLC, one is about 50ft away, and one is +100ft away. The two furthest 7017s have biasing and pull-up resistors installed.

I got rid of the part of the code which, after complete failure to connect to a 7017, it would stop trying on later cycles. The result is that I /sometimes/ get successful connection and sometimes fail. I added an "attempt" counter and a "failed" counter to calculate the success rate, so I'll have that statistic next time I make it on-site.

Elsewhere in Tech Support it was suggested to use the U-485 to watch the RS485 communication as it's happening. I have purchased a U-485, loaded the driver and my computer is recognizing it. I also loaded up the Realterm SourceForge terminal software I saw suggested elsewhere in TechSupport http://realterm.sourceforge.net/. From reading the SourceForge website, I think I want to "Spy" the communication. When I try that in the office (nothing wired up) I get a pop-up demanding a donation ($20) before I can use this option. Is this the option I need, or should I use "Monitor"?

Once on site, I will wire up the U-485 as shown here: http://www.tri-plc.com/drivers/U485-Drivers2009forCP2102/CP210xSetupGuide(English).pdf on page 3. (I wont be using the 120Ohm resistors.) What isn't shown is the relative location of the PLC. If I have occasional success communicating, can I wire the U485 directly to the COMM port on the PLC (without resistor) to do the spying? Aren't the needed resistors and pull-up stuff already there for comm with the plc?

So, assuming I make it that far, what next?
If I need to use "Spy" then I click the "Ports" tab, set the Baud to 9600 (default for PLC and what my 7017s are set for) and make sure the port is set to match the location of the U485. There are many other options to select at this tab and I don't know what the rest of it means, so if there is more to do, please let me know. At some point I'll click the "Spy" button and, if I've made my donation, /something/ will happen. What will happen? and what does it tell me?

My plan is to go on site as soon as I have a clear plan of troubleshooting. Right now I'm unclear on how to use the U485 to troubleshoot.

13
Technical support / Re:Program execution takes longer than Clk:1.0 Clock?
« on: May 14, 2012, 04:41:52 PM »
I was considering switching over to the method that you describe. The way it worked out it my head was going to use more DM fields (which means writing to memory) and more lines of code. The result, I think, is even slower code execution.

As an update to my weekend test, after ~2.5 days I found my counter was 0.08% behind what it should have been if it executed successfully every 5 seconds. This wasn't a robust test, but it does show that the problem is small. If I consider that each flow sensor only has flow 1/2hour of each day, my end of year total error looks to be 0.25% We have decided to ignore the error for now, and I'm keeping my fingers crossed that the problem is in fact as small as my little test makes it seem.

14
Technical support / Re:RS485 with 7017
« on: May 14, 2012, 03:31:23 PM »
Great news about the CAT cable, one less line to run.

The set-up as described above, using Aref, will only output 10.06V on a F1616-BA. To get 5V, I'm connected to DAC#4, and used the SetDAC 4,2048 command. ARef is not user selectable, it is either 5 or 10V, depending on the PLC.

Otherwise, I'm in business. Thanks!

15
Technical support / Re:RS485 with 7017
« on: May 14, 2012, 12:01:35 PM »
I'm ready to take your advice and use the DAC from the AN20MA-2 to make the pull-up resistor to terminate the RS485. The termination will be 100+ ft away from the PLC. I have a few questions as to how I should proceed.

I have 8 strand CAT-5 cable that I am planning on useing to carry the RS485 signal. Can I use one of the wire pairs to also run power from the PLC to the Pull-up resistor? Or will this cause signal interference?

I believe that the pin on the AN20MA that I'm supposed to use is the Analog Ref. (AREF(out)),and that the complement is AGround.

I added the following line of code to the "1st Scan" rung.
SetDAC 7,2048 'Or some value larger than 2048

I then measured the output of wires connected to the ARef and AGnd with my voltmeter and didn't see any voltage or mAs, so I'm doing something wrong. I don't have any resistors connected, just trying to measure directly.

What am I missing here?

EDIT: I think what I'm missing is the power source to the AN20MA. In the AN20mA instructions it calls for power to the AN20mA to power the 20mA output. I have a transformer providing 24V 2A to the PLC. I think I need to connect V+ from the transformer to 24V on the AN20mA, and V- to 0V on the AN20mA.

Pages: [1] 2 3