Q02 Scantime increase when deleting comments online

[stl 0]

Hi, Hopefully someone can put me right with a problem i'm having! Basically i want to delete some redundant code and the rung statements(comments) associated with it. I'm using GX Developer 8.30 and I'm trying to do this in Monitor (Write mode). The problem is when i delete the rung statements and confirm with F4 (Convert) i can see the scantime increase in the system monitor. Joking aside, before i reloaded a backup, i managed to go from 6mS (normal) to 50 odd mS ! disconnecting and reconnecting still shows the higher scan time. These comments must be stored in the PLC because they are present in an upload. What am i doing wrong and secondly how do i delete all the comments taking up valuable memory?

[Gambit 326]

As far as not having the the statements in the program >> Edit Documentation statement/note block edit Select all comments by pressing the top left corner. Select in peripheral Change type But this can't be done with on-line change!

[Paul Ked 0]

The scan time will fall back to it's original value once you Stop/Run the PLC. Don't ask me why though Regards Paul Ked

[stl 0]

Thanks for the advice - Ill give it a whirl later on the "Night Shift"

[stl 0]

Hi Guys, I have a question regarding statements, If you are online in write mode and you add a some text to a rung, after converting, is this text then loaded into the PLC the same as a programming change? Will Gambits method permenantly stop this or do you need to clear it after you have finished adding new statements? Hope this makes sense?

[funfrok 0]

Which series of plc do you use? Statements can be stored on plc, and it can be written to plc with write during run. Write during run increases scan time temporarily (end processing). If you are in monitoring mode, the scan time you see is maximum scan time. In your case, that is the scan time when you did "write during run". When you reset PLC the maximum scan time is reset so you see shorter scan times. The PLC doesn't run faster, only misrepresentation is solved.

[Crossbow 296]

You can add or remove embedded statements in online edits. But you cannot do a batch edit and replace online, just as Gambit said. The scan time shown in GX Developer monitor toolbar is a maximum value. Check data registers in the SD range for the actual. Current scan time is 32-bit number in SD520. Min SD524, max SD526. All 32-bit binary.

[speakerman 4]

Odd isn't it that only the maximum is shown, and not the current. I've had to work around this to check the scan time during mode activations to maximize encoder tracking accuracy, and it was weird to have to hunt for it. If there's a Mitsu rep reading this, take note! Such an easy thing to have up on that monitor window, both the maximum and current... speakerman

[Crossbow 296]

I've mentioned to Mitsu before that should be the current scan time, or else it should be user selectable.

[panic mode 246]

i don't see much of a problem. certainly there are couple of things that can be improved with development package but it doesn't take long to learn it's features, there are decent manuals that help that process and the question was answered in reasonable time. (i wish all my Siemens questions got replied this fast) encoder accuracy should not have anything to do with scan time. anyone looking for processor status should get that status from the processor itself - and this is documented feature. even if it wasn't, it takes just few instructions of own code to measure scan time. are we programmers or not?

[speakerman 4]

You're right panic mode, it isn't a problem, more of a minor preference. When I first noticed that scan time register in the monitor window, it seemed to me to be a maximum, as it wouldn't update in the downward direction. It wasn't hard to find the special register designations for the three different scan time values, and lay small numerical displays on the HMI. Really clear, actually, and I'm glad it has the maximum built in. I have had to trap that value in other processors with code. I guess I'm saying that considering they went to the trouble to build those registers, they could show them off a bit For us it's just another part of a learning curve that you are, thankfully, far past the bottom of because I notice how much you help people here. As a new user still rounding the first turn, I have to say that most of the difficulties with this system have been "simple" items. There's noone around me who knows a thing about Mitsubishi, so there wasn't anyone to ask. You should have seen me trying to figure out how to type in a timer coil for the first time. It was comical! They look a certain way in the manuals... I spent about an hour looking through the menus for a "timer" selectable bit, typing various things into the F7 coil, pouring over the manuals for something other than a picture of how it looked when it was done. Great descriptions of what they do, how they work, etc. Really good! Nowhere does it say that you type it "T1 K20" that I could find. I would never mention something like that as a criticism, because it was so basic, and my own fault for doing this without at least a little support. Throughout all the things I've learned there are powers and features that I have really grown to appreciate. A lot of it is really quite intuitive. Some of the things mentioned are merely preferences, and that's me trying to contribute to the system becoming enriched and strengthened for future users. Some of them are not criticisms, but suggestions based on programming needs that have cropped up. I did read that pinned thread on possible improvements and I can see some real venting has occured, which may make people a bit touchy. Considering the intent of this forum and the spectrum of humanity, it's going to happen. Respectful contrary always seems welcome, and that's why I keep coming back. When performing machine upgrades I can always tell more about how friendly a system is to use from the newbies than the lead hands. The lead hands can tell you anything about how it works, and they are the people I trust to properly describe the operation, and the problems that occur. They've often accepted certain difficulties as normal, however, and no longer regard them as something worth the effort to correct - even if that effort is very low. We all want to go after the big fish, but if you add up enough small fish you've got a full stomach. It's up to me as the control strategy designer to weed out the normal learning curve items from the real opportunitites for improvement. You might say I criticize for a living. Dang, must be why I have no friends... The accuracy of the encoder itself is not related to scan time, but the amount of machine movement measured by comparing the position pulse value differential each scan determines overall accuracy. At a certain threshold of scan time, it will also become impossible to count rotations reliably. This is why I was asking if anyone knew of a rotational counter, or a cumulative pulse counter, so my scan time would stop being a factor determining maximum rpm. Guess I needed to be clearer on that one. To properly program my positioning logic I need to monitor both current and maximum scan times, one for ultimate resolution, the other to determine the rpm at which the logic fails and the heads sail around unchecked. Another example is the job I just finished this last week. It was on a Modicon, and they were having very intermittent problems that were serious in nature, real mechanical crashes. It turned out to be scan time, whereby the normal cycle was 20 ms, and the maximum was 65 for a short time about every seven minutes. It turns out that code for part of the process was not robustly written, so it pulled the whole processor down when it was active. Many critical items are positoned with encoders - which all became three times less accurate - and some sensors were only activated for as short as 50 ms. So during that time, if a critical event was happening, "random" parts of the rest of the process could fail completely, or intiitate something weird when it relied on two sensors activating together. We re-ordered the press discharge cycle code to stop being such a hog, and set up critical sensors to trigger longer, and that problem was solved. Happy days! Thanks for the posts on the encoder pulse monitoring thread Got some good stuff going on there, hoping I can finally be of help to someone else. Have a great weekend, speakerman.

[panic mode 246]

timer eh..? i remeber spending time on that one on my first job... i think i may have mentioned this in my AB to Mitsubishi transition guide (older reply to one thread).