Jump to content

LPK

Members
  • Content Count

    28
  • Joined

  • Last visited

Community Reputation

0 Neutral

About LPK

  • Rank
    Member

Recent Profile Visitors

1,673 profile views
  1. Hi there, Does anyone have any specifications on the accuracy of the real-time clock in the UniStream PLCs? I am using one (a USP-070-B10) for an application that monitors a very slow-changing system, and so needs to be accurate (hopefully at least to the nearest second) over a number of consecutive days. Sometimes tests stretch into weeks. I recently (about four weeks ago, but I’m not absolutely sure) noticed the clock was way off and synchronised it with my computer clock (which is accurate and auto-updates, etc.). This time I checked and it was between 4 and 5 minutes out, so seems like it might be deviating by about a minute a week. This is a real problem when we need to match up data on this system with data on other logging systems – it should not be more than a second or so out at any time if we are to do that accurately. Also, is there any way to get the system to update with daylight savings time, so the clock does not need to be manually reset at these points? Thank you for the advice.
  2. Thank you for this. It's good to know at what point the inputs are sampled. So if I choose the option that averages 7 readings, that will essentially be the average of the last 7 readings (and thus the last 7 scans)?
  3. Hi all, I see it says about the filtering/smoothing/averaging on input channels that there are options that give you no averging, 3-reading, 5-reading or 7-reading averages on input channels, but I was just trying to work out over what kind of timespan this would occur? Do the channels get sampled once every ladder cycle, so the moving average timespan might be (up to) 7 ladder cycles in duration, or would the ladder rungs all be executed and then the inputs sampled (up to) 7 times in succession, making the time span only one ladder cycle? Or do the input channels get sampled on some other kind of demand system? Thank you in advance for clearing this up!
  4. Thank you for the reply. I'll have another go at this with your instructions when I bring my laptop to work again!
  5. Hi all, I've been programming a UniStream PLC for a while now and have had to now install it in another room. I has always (as far as I remember) been fine programming it here on this desktop PC (Win 8) but now I've had to move the PLC to a test room I've had to try and program it over USB using another computer (a Lenovo Yoga notebooky-laptop type thing running Win 8.1). I've installed the UniLogic software as before, even uninstalling and reinstalling again, making sure I installed the second time using "Run as Administrator" on the installer, in case that didn't allow something to install properly the first time. With both the first time around and second time around install, the programs all load up fine and everything else looks the same as it ever did on the version I have on this desktop PC (the latest version, Ver. 1_9_Rev_19), but I can't get my laptop to connect to the PLC. I have tried things I've found on this forum, like: powering off the PLC and trying again; powering off the PLC, unplugging the USB cable, closing UniLogic, killing the Unitronics Notifier (via the Task Manager), restarting UniLogic, powering on the PLC, and after the PLC has booted, plugging the USB cable back in. I have tried all kinds of combinations of these things, multiple times, and still ahve had no response from UniLogic when trying to connect to the PLC. Sometimes (though rarely, compared to my desktop) it comes up with the message about connection problems ("Connect PC to PLC ... If a PLC is ... not discovered ..." etc.) in the PC-PLC Communication window, but when I press the Refresh button/hyperlinklink, where it usually says (on my desktop) "Searching for hardware. This may take a few minutes, please wait...", for maybe 5-10 seconds and then finds the PLC, on my laptop it immediately returns to the "Connect PC to PLC ... " message, as if it has definitely and quickly not found anything. The behavior seems very definite about not finding anything. There are 2 USB ports on the laptop; one is USB 3 and one is USB 2. I have tried all of these things in both ports, several times. with restarts in between and everything else I can think of. Please help,. I don't wan tot have to move this desktop computer to the PLC, as there's no space to use it in the test room!
  6. I'm glad you think so, too! Thank you for the reply.
  7. Thank you for your reply. I thought the manual resetting of the button bit (just after changing the screen change bit) was the way to go. Changing the screen when the button's released seems like a less intuitive thing for the user to do; they'd have to wait for X seconds and then release the button. But if released early, it wouldn't change the screen and might leave them confused, so it would really require another item on the screen to say when it's OK to release the button. The first way (manual resetting of the screen change bit), the screen changes, and that tells them when to stop poking the screen. It still seems funny to me that the button isn't considered to be released when it's no longer available to push. I'm not sure what circumstances you'd want to consider a button pushed if you'd moved to a screen where it no longer could be.
  8. Hi there, I was making some buttons that would allow me to go from screen to screen and when I do this with buttons "normally", so that the button sets a bit and that bit triggers an action to change the screen, all is OK, as changing the screen this way (via the action itself, maybe?) seems to reset the bit back to being zero when the screen changes. The trouble came when I wanted to change screen, but only if someone pressed a button for a certain amount of time, as a kind of integrated "safety" – I don’t want them to press the button accidentally when it does something important or when it takes them to a place that I don’t want them fiddling around in accidentally. So I use a button to set a bit when it’s pushed and reset the bit when it’s released. That button press bit counts down a timer when it’s set. When the timer’s .Out bit is set (i.e. it’s counted down), I then use that to set the screen change bit. I note that as soon as the screen changes, the screen change bit is toggled back to zero, but the button pressed bit remains set, despite the fact that I can’t be pressing that button any more, as the screen’s changed and so the button’s not available to be pushed any more. To me this seems like a bug, as changing the screen should be like releasing the button (as I say, the button’s not available to be pushed any more) and so the button press bit should be reset. Any ideas?
  9. Yes, I've updated the software and firmware recently and I'm on UniLogic 1.9.19, plus the Firmware Manager says the UniStream firmware is 1.9.6. The cyclic file size changing thing I was mentioning was that when you look at the files in the DT folder on the PLC (I was using FileZilla over the Ethernet connection), and update the view of these files regularly (pressing F5 ever second or so), there was a .csv file, with the same name as the file name that was being logged to, (e.g. "Data_2014-12-12_18'24'37.csv"). This file was not inside a .zip file, and, even though after the logging to that file was stopped, the file was seen (when refreshing FileZilla’s view of the files in the DT folder) to grow in file size from very small to about 7.5 MB, then another strangely named file, like "ziFheLDg", or "ziMqNiMw" would appear. Then that file would disappear and the .csv file would return back to a small size. That would keep happening, and the size of the .csv file would grow again, in a repeating cycle. As I mentioned before, it seemed like it might be the PLC regularly re-writing the UDTF file to a CSV file, then zipping it into a .csv.zip file (I've noticed when zipping things on my own PC that you get intermediate files as a zip process is in progress, when the zipping process is complete and the zip file has been written. But this behaviour was continuing after the logging had stopped, so the .zip file didn't really need re-writing. But that’s just a guess of what it might be. Other contributing factors might be that I was asking the PLC to do a lot in each ladder cycle (or at least some of them). I was working with large DTI tables, and have seen several watchdog timer issues, where the PLC has stopped, and so I've put a stopwatch in the ladder to tell me how long each ladder cycle takes (the time it takes between each return to the end of the last function in the ladder, using the stated stopwatch resolution units 64/66,500,000 seconds). While some cycles are relatively short, at about 3.5 ms, whenever a new row is added to the top of the large table (8640 rows, with 2 columns of strings, 12 columns of reals and 3 columns of bit data), the ladder cycle time reaches about 225 ms. This was a pared back table, as previously this was causing a lot of PLC CPU stops. It’s a shame that there’s no alert when this happens so that the user can be told to restart the PLC – as in some ways it still looks like things are working (like you can still move through the screens, use some on-screen controls, etc.), but the CPU has stopped in the background I have tried leaving the PLC on for a long time with the logging all turned off, and deleting all of the old data (.udtf and .zip files) from the DT folder, and the PLC is not showing the same signs of the cyclic file size changing .csv file or the appearance of the oddly named files. So either leaving it for long enough to sort itself out or deleting the old files off the SD card seems to have helped. If I update the view in FileZilla very quickly, I sometimes see the .csv file now, but it doesn’t seem to be so prevalent or permanent as it was, even when the PLC is pushed to log to file very frequently. I think pushing the PLC to do so much in some ladder cycles may have affected the reliability of the system and its ability to definitely write data to file(s) at precise and regular intervals, anyway. It might also have contributed to seeing things (like the .csv file cyclically changing in size, etc.) that might otherwise happen so quickly in the PLC’s ladder cycle "downtime" that they don’t normally get seen. I am going to back off the tasks that I'm asking it to do, as this reliability of saving the data to file is key.
  10. As an update, I carried on playing with this, and when I deleted the "Data_2014-12-12_18'24'37.udtf" file to see what that would do, the writing to CSV file stopped altogether. It even stopped for the Data Sampling function that I had set up in the same project, when I turned that on and off a few times. Updating the program on the PLC didn't work and a few resets did little either. Some time later, though, it seemed to come back and start writing a csv.zip file, again with the odd cyclic filesize-changing .csv file. but it was not making a CSV file (in a ZIP file) of the most recently saved file, but the one just after the deleted file, (i.e. the "Data_2014-12-14_03'46'06" file), not the other files that I saved to after that one had been created. I have saved many files since, turning this logging on and off, and it's still going around and around, cyclically creating a "Data_2014-12-14_03'46'06.csv" file (presumably saving it into the "Data_2014-12-14_03'46'06.csv.zip" file). I think I might have to delete all of the files and see what that makes it do... So many of these actions are totally opaque and there's very little to tell me what the PLC's actually doing.
  11. Thank you for the suggestion. I don't think that's possible in this case, as I had the bit set with a constant ("#1"), so it was always set when an individual row was written to file. Unless there's still some way it could become unset? As I mentioned the reason why I was not writing multiple rows was because I was using the Insert Row in DTI function to fill my DTI table, as that was a good way to do it, but then you end up with oldest data at the bottom and newest data at the top, as opposed to the file, which is filled from top top bottom (appending data to previous data). So if you wrote a block of rows from the DTI, then it'd be in reverse order compared to the rows above and below that block. I need to write the rows to file fairly frequently, as the user might stop the PLC at any time and expect all of the data to be saved on there, so I save rows of data as they are sampled/calculated, unless the system is in the "unknown" state I described.
  12. Hi there, I am having issues writing data from a DTI table to file. I created ladder logic to write data to files on a regular basis. I couldn’t use the normal Data Sampling functions, as although I need to log to file regularly, there are times when the (measured) system state is unknown. At these times I have to stop regularly logging to file and wait until a certain period has elapsed before I can accurately assess the system state and start logging to file again. So what I do instead is regularly write a row of data to a DTI table, inserting it at the top so that the rows all move down one, using the Insert Row in DTI function. When the system state is known, I write a row of data from the DTI table to file every 2 seconds. When it is unknown, I record the row of data in the DTI file, then when the system state becomes known again, I "catch up" writing all of the rows I have not yet written to file from the table, one at a time. This has to be done one row at a time as the files are appended to one row at a time and so the oldest data is at the top of the file, but at the bottom of the DTI table. I am logging rows one at a time using the Store DTI to File function, appending to file and using the CSV option to make sure I get a CSV file as well as the default UDTF file. This is because it’s easier for the end user to open a CSV file rather than have to convert it first, even if it does come inside a .zip file. I was sent a converter that converts UTRF and USMP files to CSV, but not UDTF files - is a converter available? When logging to file, I start at a certain time and use that as a date/time stamp (in the format yyyy-mm-dd_hh'mm'ss) for my file name, so before the weekend, I set the PLC logging every 2 seconds, and it started with a file name of "Data_2014-12-12_18'24'37". I set the ladder up so that if the number of samples in the file exceeds 60,000, then the file name changes, so that I can start logging to a different file and so split up the data into multiple smaller files that will open, even in old version of Excel. So after a couple of days, it made a new file name, "Data_2014-12-14_03'46'06" and started logging data into that. The issue is that while the PLC made both a UDTF file (which I can’t open) and CSV file (in a .csv.zip file, which I can open) for the first file ("Data_2014-12-12_18'24'37.udtf" and "Data_2014-12-12_18'24'37.csv.zip"), it didn’t make a CSV file for the second file. I have looked for these files on the SD card of the PLC using both Uniapps and FileZilla, via FTP. There is more (perhaps linked) strange behaviour when looking at the SD card contents via FileZilla/FTP, and pressing F5 regularly to refresh the view of the contents of the DT folder on the SD card. There is, in the DT folder, a .csv file, with the first file name ("Data_2014-12-12_18'24'37.csv"). This file is not inside a .zip file, and, even though the logging to file is now stopped, the file is seen to grow in file size from very small to about 7.5 MB, then another strangely named file, like "ziFheLDg", or "ziMqNiMw" will appear, then that file will disappear and the .csv file will shrink in size and then grow again. This seems like it might be the PLC regularly re-writing the UDTF file to a CSV file, then zipping it into a .csv.zip file, but that’s just a guess. But the thing is that it’s still doing this for a file that’s already been written to, and so doesn’t need re-writing to a .zip file. When the file name has been changed and a new file is being written to, how can I get the "also save as CSV" option to stop writing the old file to a .csv.zip file and start doing it on the new file?
  13. I second Y. INDS' comments. I have seen exactly the same messages, under the same circumstances.
  14. I do wish there was an easy way for the ladder logic to pick up on what files are on the SD Card and allow people to delete them, or trigger something that could be "delete everything that is over a month old", "delete the oldest 10 files" or something useful like that, just so that they can regularly do some clear-outs on the card data. I'm not really sure I want users having to go through UniApps to delete stuff via a slow process of poking the screen, or even be in there fiddling with the PLC's underlying stuff... I'd rather just having something that does a fixed thing (like clear out old files) and keep the users on the main screens, to keep it al simple and controlled. Unless, of course there are other, maybe remote ways to get access and do this more simply via some kind of app. I've managed to use FileZilla to access the files on the PLC and I find it the easiest way to get data table files and "Data Sampling" output files onto and off the PLC. Doing it that way means you're not limited to doing things just one file at a time, too, as you seem to be in UniApps (and it therefore means it's all a lot quicker). So I think I'm going to have to recommend that method to users (though it does mean that they could end up deleting some other vital files!) I think there was a video tutorial on the subject(s) of FTP, Ethernet, etc. that tells you what settings you need to change/set up.
  15. Hi Eyal, Thank you for the reply. Yes, I found the larger comment at the top, and have divided my code into sections, but I find myself wanting to comment what's going every few rungs at least, as I often go off to do completely different things and come back to find some parts unclear (I hope it's also useful to others if they need to pick my code up and understand it). I like that the ladder rungs expand in size to allow the parts within to be seen, and it'd be nice if the comments could do the same. It's kind of frustrating when I scroll down the ladder logic using the mouse scroll wheel - if the comments above the ladder rungs go beyond the one (and a half) line limit, then they scroll to the bottom line of the comment as the ladder rung scrolls past the mouse pointer, so you end up seeing the bottom of the comment rather than the top.
×
×
  • Create New...