Damian

Correct me if I'm wrong, but I think the main reason behind the moderation is to eliminate the SPAM posts. Probably the second highest reason is to make sure people are "watching their mouths" so to speak. What would be nice is for those of us whom use the forum often and without incident eventually attain a rating (user level) that means we can for the most part be trusted and no longer require that our each and every posts get moderated. Once someone has posted 50+ times without abuse it would seem a fair bet that you could "slack the rope" a little. Another possibility is maybe you could have users with higher priveleges based on tighter screening (interview, registration, waiting period) etc. Just some ideas to throw out there.

Do you have the output setup as PNP or NPN? Are you using a function block in the ladder to control the pulse or are you using the dedicated feature in the hardware setup?

Phil, Great article. I think this feature is often overlooked because it is assumed that it isn't allowed. Some also look at it unfavorably because if you are not careful with your coding you could create a lot of havoc. From my perspective, that is true no matter what your doing. Hopefully some day Unitronics will address it in the documentation so that users can gain a better level of comfort with it.

Hi Simon, I have used this structure myself several times when it was necessary to complete a series of iterations within one scan. I can say with a large degree of certainty that it in fact does prolong the scan it is on and not simply start back at the jump label. In the old Forum you will see a topic call "Implementation of FOR loop" (or something like that) where I reference having actually made a test program that allowed me to determine the effect on scan time as iterations increased (or complexity of the loop). Although Unitronics does not explicitly state that "jumping back" is allowed it does not seem to prevent you from it. I suspect they may not advertise it because it opens the door to a lot of tech support headaches as it could easily be misused if the person implementing it does not take care writing the code or does not understand how the PLC processes the overhead and scan.

Regarding the Data table function blocks ........ Will the function block always process in one scan? Are there instances where a Data Table function may take take several scans to complete (such as some of the screen loading features and the like). If I use the "interval" function across a DT function block, is it giving me an accurate account of exactly how long it is taking to process? Is there any portion of the process that gets handled in the overhead time between program scans? More to the point, can I rely on the fact that one that network has completed, that I can be certain that the values of the DT operation of the previous network was completed in its entirety and that it is dafe to use the data as if it were so?

Unitronics Support Downloads Visilogic VisiLogic 8 6 1 Bug Report Describes fixes and known issues in version 8.61. Click to open...

What is the most current version of Visilogic? I downloaded a document labeled "V8.6.1 Bugs Fixed", but it also references a V8.6.3 which intuitively would lead one to believe is the more current version. As usual, I am confused.

Hi Phil, Thanks for the feedback. I'm running 8.6.0. It's tough finding these types of anomolies. Especially with all the variables regarding operating systems, service packs, hardware, security settings, anti-virus,etc.) It's bizarre ....... Visilogic (and everything else) will grind to a crawl. I'll close it, re-open it, and all of the sudden everything is happy again. Thanks for putting the theory to test at least. It's helpful even to know that it is not that way for anyone else. Damian

I am beginning to suspect a pattern regarding Visilogic and PC speed running under XP pro. It seems as though if you are online with the Unitronics controller via a TCP connection that over time it brings the operating system to a crawl. After having taken Visilogic Offline and closing the program all together my PC went back to normal. There seems to be something Visilogic is doing that continues to munch away at system resources as time goes by. Anyone else notice anything similar? D

I am going to go out on a limb and assume I speak for all of us, but unless the info gets stuffed into the new forum in some fashion I think we would all benefit from it being there forever. Can't imagine it takes up much resources. D

Simon, Exactly! D

Hi Emil, The DF1 document is actually quite helpful. There were some explanations, corrections, and clarifications that found their way on the old Forum which would be of great benefit to be merged into the document. There are also some translation issues that make it a difficult read in some spots, but it is definitely valuable. If they are OK with it, I am willing to edit their version of it to get it more up to date. My Modbus issue is solved (for the most part). JT hit the nail on the head. As I mentioned before, I've had Uni's talking modbus to eachother before, to mocking that up again wasn't going to do me a whole lot of good. Somthing now obvious is that there is an issue with the reliability of the DF1 communication between the AB and the Uni. When I have the two talking DF1 I get very frequent comm errors and prolonged timeouts before communications kick back in. Changing absolutely no hardware (Exact same cable between the exact same ports) and using ModbusRTU instead, I have run for several hours now without one single comm error or timeout. This is all with the same comm settings as well (38400,8,N,1). The only change made was protocol. I wish I had more time to figure out where the problem is, but now that I have the communications working in Modbus I can't afford to spend too much time with the DF1 at the moment. Perhaps when the job is finished. Thanks for your help, D

Joe, It's official. That was crux of the problem. At least in the end. In the beginning I had the ladder correct but must have had something else messed up. By the time I had fixed the real issue I must have already screwed the ladder up. It's time to go soak my head in a bucket of water. Many thanks! D

Hi Emil, Thanks for the note, but you may not have noticed my post a while back regarding having issues with the reliability of the DF1 communication. It should also be noted that there are some errors in the document you mention (and in the help files) that should be corrected. I've done quite a bit with mobus RTU on the V570/V280 with success so this is nothing new to me. If fixing the programming error that Joe pointed out does not fix the problem I will send the application into you guys to have a gander. Thanks, D

Hi Joe, You raise a good point. I did originally have the SCANX on its own network with no conditions in front of it, but it wasn't behaving any differently though. But now I can't remember if there were other problems previous to that I may have latter corrected. I'll give it a try in the morning and see how it goes. Thanks for pointing out the dumb mistake. I'm going to be very angry with myself if that was all the problem was. D

So ................ Having been unable to get any reliability using DF1 communication between the L35E and the V570, I decided to try and see if using modbus RTU between the two would get better results. For some reason, the V570 doesn't seem to be responding to the Modbus commands. I have the L35E acting as a master using the standard Uni programming cable between it and Comm 1. Using "Info Mode" I can see that all the parameters are set OK and that Com1 is set for Modbus. When looking at the receive buffer in Hex mode I even see the Mobus messages coming in perfectly. Everything seems to be framed and formatted properly. So I know that the data is getting to the V570 fine. It just refuses to respond to it. I hooked my PC up directly to the output of the L35E and monitored the port with a modbus sniffer. The software had no issues picking up the communications. Attached are some screen shots of the setup. Any thoughts would be greatly appreciated. D

Hi Stein, Thanks for the info. Specifically, my question is "why isn't this function built into Visilogic?".

It would be nice to have the ability in Visilogic to export the online values of the operands to an excel files. It would be even nicer if this feature also exported the Descriptions along with the values.

Saragani ...... Thank you! That is much easier than what I have been doing.

Is there a reason why we still have to add images to our posts indirectly through a URL as opposed to directly? I was under the impression that this was going to be one of the nice new features of the new and improved forum. D

Enhanced model

I put you in charge. You'll have to determine that. Might I suggest a kitten?

Just size Cara. 1) My customers want larger screens. No seriously, they just want them. Just because something isn't needed doesn't mean it isn't wanted. (ie people don't need 50inch LCD TVs either. I say "give the people what they want" 2) It is quicker and easier to develop for larger screens. The smaller the screen the more time I have to spend (fitting, sizing, nudging, strategizing and compromising) to get the job done. The more I have to bust up into smaller screens, the more work it is for me. Same for the operators. If you bust things up into a gazillion screens, the more time they have to waste "hunting" for what they are looking for. 3) The larger the screen, the larger I can make the buttons and numeric fields. This decreases the chance that somone with "fat fingers" will accidently press the "Pie Eject" button when they really meant to push the "Bake Crust" button. Below is a screen shot of a "canned" manual servo axis screen I developed. It is a very busy screen. There is more I would like on it, but there just wasn't enough room. (ie. would have liked to have staus of limit and home switches, text fields to indicated any faults, Fine and Coarse Jog buttons, etc.). Sure I could put these on another screen. But it really belongs on the same screen. Sure I could have made some things smaller, but I don't want the user to feel like they are playing the game "operation" and trying to hit the fields with the tip of their finger nails.

Cara, You are too cool. Thank you!