Jump to content

Recommended Posts

Greetings all,

I would like to propose a couple of System Bits added to the OS - Data Table Read Success and Data Table Write Success.

It doesn't matter what table was read, what data, or anything else, just that the last DT command executed successfully.

Thanks,

TM

Share this post


Link to post
Share on other sites

Hi Tim,

The idea of bit, stating confirmaiton of the operation, is, when this operation for some reason takes more than one scan. Giving the command to perform the relevant operation, the controller continue its normal scan. In many cases you want to know when the operation is perfomred to go to next relevant action.

Read/write to DT is performed immediatelly. The controller perfomrs it and then continue the scan. You can put operation, depending on the DT read/write on the next scan after relevant DT module and you can be sure this operation will be executed.

Why you think such "confirmation" bits are needed?

Share this post


Link to post
Share on other sites

As stated in a previous thread, I have a 280 project where the data table is sporadically not being read out. I don't understand why it is not coming through, the code is very simple, but if I had a bit confirming the read took place, I could verify it.

I can always add a column to the table, an MB set to "1", and reset the MB in ladder before reading. When the bit goes to "1", I know the read finished. But I thought a system bit would be better, since anything in the OS reduces my ladder overhead.

Thanks,

TM

Share this post


Link to post
Share on other sites

As stated in a previous thread, I have a 280 project where the data table is sporadically not being read out.  I don't understand why it is not coming through, the code is very simple, but if I had a bit confirming the read took place, I could verify it.

I can always add a column to the table, an MB set to "1", and reset the MB in ladder before reading.  When the bit goes to "1", I know the read finished.   But I thought a system bit would be better, since anything in the OS reduces my ladder overhead.

Thanks,

TM

I had the same issue. I got the same answer. "It is immediate" you can be sure.

But its not, at least not always.

SO I had to study it myself and here is what I found to be true.

If you use a positive transition bit in front of any data table function, your success is not guaranteed. Some number of the DT commands will not happen.

Also if you put multiple DT functions on one line, sometimes the first command will execute, but the last one will not.

I was doing both of these things. Drove me nuts. If the positive transition is true for the whole scan, and ALL the DT functions are done immediately EVERY time, then it should work EVERY time. 

But it doesn't.

Now I needed the function to happen only once with specific data RIGHT NOW if X was true.

So I set a bit to initiate the function and place the DT command right after the set bit and then placed a reset for the first bit right after the DT function. This worked every time with out fail.

I also have added an extra MB to the data just to mark if data was recorded. I use this extra bit to trigger my FIFO to shift data down one row. That way I can always look at the same column of data to see when something is written to the row. Some data might be blank sometimes and most of my data are integers so it is easier to have that extra MB to compare with.

The data tables do not work the way UNitronics thinks they do. Or at least not he way they explained it to me.

Share this post


Link to post
Share on other sites

Can sopmeone send a demo to simulate the problem to support@unitronics.com? Which VisiLogic and OS version you're working?

The operation must be immediate. We need to investigate and see whay in some specific cases it's not. Then we will find soluiton.

Waiting for simple (as simple as possible) demo to show the problem!

Share this post


Link to post
Share on other sites

Can sopmeone send a demo to simulate the problem to support@unitronics.com? Which VisiLogic and OS version you're working?

The operation must be immediate. We need to investigate and see whay in some specific cases it's not. Then we will find soluiton.

Waiting for simple (as simple as possible) demo to show the problem!

I think part of the problem was also because of the complexity of the program. It had around 2000 kines of ladder several DTs and several FIFO DTs , one DT had 1000 rows used as a FIFO. The scan time was 15ms. And there were 6 inputs used in an interrupt routine for measuring fast counts of flow meters. Not sure what specific thing made any difference. Not sure if any of it made a difference.  

I am pretty sure we discussed this when I was having the problem. I sent some examples of the rungs that did not work back then, but a solution was never found.  So I found a way that works and let it go.

Now I just follow a couple simple rules I have discovered to make it work better.

If I have time, I will try to simulate the problem and post it.

Share this post


Link to post
Share on other sites

I think part of the problem was also because of the complexity of the program. It had around 2000 kines of ladder several DTs and several FIFO DTs , one DT had 1000 rows used as a FIFO. The scan time was 15ms. And there were 6 inputs used in an interrupt routine for measuring fast counts of flow meters. Not sure what specific thing made any difference. Not sure if any of it made a difference.  

I am pretty sure we discussed this when I was having the problem. I sent some examples of the rungs that did not work back then, but a solution was never found.  So I found a way that works and let it go.

Now I just follow a couple simple rules I have discovered to make it work better.

If I have time, I will try to simulate the problem and post it.

Hi Dah,

The 15ms scan time you were getting .............. was this the average scan time or were you performing all your data table operations every scan? Did you ever do anything in regards to trying to capture the max scan time?

With what you and Tim are explaining, it almost sounds as though during the DT execution the PLC may suspend operation and goes to service something else momentarilly (perhaps checking IRQ states, etc) and when it returns to complete the DT execution it forgets the proper state of the transition that enabled the function.

D

Share this post


Link to post
Share on other sites

Hi Dah,

  The 15ms scan time you were getting .............. was this the average scan time or were you performing all your data table operations every scan?  Did you ever do anything in regards to trying to capture the max scan time?

  With what you and Tim are explaining, it almost sounds as though during the DT execution the PLC may suspend operation and goes to service something else momentarilly (perhaps checking IRQ states, etc) and when it returns to complete the DT execution it forgets the proper state of the transition that enabled the function.

D

Scan was read from the SI "scan time" I was never terribly interested in nor had the time to launch a full scale investigation as to "why" any of this was happening.

However, after that project was done, I ran into the same exact issue on a totally different project. The second project was much less complex, used no interrupts, or immediate updates and the scan time was less than 6 ms.

This is when I implemented the "rules of using data tables"

No leading positive transition bits.

Only one DT function on a line, maybe 2  if you have to, but verify it, and never 3 or more.

If you want the DT function to happen once, set a bit in the preceding rung, use the contact from that bit before the DT function, then reset the bit at the end of the DT function.

If you follow those, you have a better chance of robust DT function. I have had no issues since I started doing this.

Anyone should be able to repeat these issues. Get a program scan up to around 5ms and add 5 DT functions to a line with a positive transition bit. Even better, use an HMI bit. Now put some ever changing data in the DTs. One of my favorite test data is variations of the RTC. Now go look in the DT in "online" mode. You might find that some of the data is not there. Now try to send that data over CanOpen while it is changing for extra fun.

Once you are aware of the issue, it isn't difficult to work around it. Its not a big issue at all. But it is maddening when the documentation and help desk tell you "it must not do this" and that's it. 

I might have some time this week or this weekend to post a sample so we can all look at the same thing and discuss it. Maybe it's just something I do that causes the issue.

Ok maybe it's just something I and TMoulder do.

Share this post


Link to post
Share on other sites

FWIW I have also seen this type of problem. In that case the program had been written with multiple DT operations in a single ladder net. We saw that some of the operations would execute and others would not.

Moving each DT operation to its own net solved the problem.

Share this post


Link to post
Share on other sites

When I was experiencing this problem, it was a single DT Read, and a nice speed 6 mS scan time (speedy for a 280 anyway).

If I recall correctly, you reported using an HMI bit to initiate the DT function.

HMI bits are very similar to a positive transition bits, only worse, as the HMI screen changes the HMI bits are cleared, not at the end of the scan like a positive transition. This little nugget gave me a bit of difficulty for a while. 

And I saw the DT issue with a very low scan time, so I don't think it is scan dependent.

 

Share this post


Link to post
Share on other sites

Has anyone seen this issue in the enhanced series controllers, or just the older 280s? I did a torture test on my 570 and it never missed a beat, but I don't have a 280 lying around to test.

Thanks,

TM

Share this post


Link to post
Share on other sites

Has anyone seen this issue in the enhanced series controllers, or just the older 280s?  I did a torture test on my 570 and it never missed a beat, but I don't have a 280 lying around to test.

Thanks,

TM

I have used V130 and V350s and one V570.

I only had the DT issue on the V130 , but I don't use the methods that cause the problem anymore, so I don't know if it would be different in the others.

I did not consider that it could be processor specific. I always viewed it as a software issue. But you may be on to something.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...