Jump to content

Ausman

MVP 2023
  • Posts

    2,592
  • Joined

  • Last visited

  • Days Won

    175

Everything posted by Ausman

  1. Re the snap-ins, I've always been a little concerned as to how easily they fit onto the main unit. For this reason I run a strip of reduced width gaffer tape around the seam wherever possible. I know it isn't supposed to be necessary, but it just felt "right" given the "looseness" of the fit, taking into account the number of pins engaging. Easily removed as necessary but holds things together well. Never had issues. My checkups on systems routinely include an annual remove/refit/wiggle of all connector blocks. cheers, Aus
  2. Hi all, Although I am not as affected by this as slightlyloopyatthisstage Flex, I can see how it would be frustrating if you are doing it endlessly. Perhaps another solution would be the addition of a variable list via another tab on the outputs area screens. One could then go through the variable list and copy/paste, using all the innate abilities there, or do other names prior to needing them. You would then have a dropdown listbox in the variable screen for easy choosing of the already named variable, similar to the existing method of choosing MIs, SBs etc. cheers, Aus
  3. Hi schafbo, as no answers forthcoming yet, you haven't accidentally used the same MI somewhere else, perhaps? Do a right click/find to make sure. cheers, Aus
  4. Ahhhh. Thankyou Mr Mozes. I have only been trying to reach 130s. I have up till now not even read the quickstart pdf as the installation was all straightforward. I've just now had a read and it is plainly there for me to see in the list of controllers that a 130 is not supported. If only I had read it initially, but because the app is so simple I saw no need. 1). I politely request that the site statement that it is available for the Vision and Samba series be modified somewhat to say that it does not work with some models. 2). It is frustrating that I have spent a fair bit of time on this. The connection was always checked as valid by the inbuilt testing, but because it is a 130 it won't reach the final step. Yet nowhere in the app is a warning that a PLC type is not supported, if a connection is made to one. There should be. 3). If the app changes in the future to allow more models to connect, please let us all know. Thanks, and cheers, Aus
  5. And I have to ask what is the make and type of fan? I assume that the 201 is hooked into a pitot differential flow sensor or similar. I ask about the fan model because many modern variable rate fan systems have onboard functions to vary their rates directly from a sensor. It is often easier to get the fan to do it itself, and just have the plc monitor things, as the manufacturer has already done the complex maths to suit that particular model. Your setup looks small, so consider that you may be adding unnecessary complexity. Some fans also have inbuilt pitots which make things much easier as well. It is all to do with exactly what looks like your scenario....same flow rate regardless of pressures, filters getting dirty, etc. I only use the plc as the controller when there are a host of other factors involved in varying the flow rates, and these are on much larger installations than yours. cheers, Aus
  6. Hi all, But in the original post isn't the problem that there is multi-step control needed? Are you suggesting consecutive separate PIDs, Hightech? Or is there a method of doing it all in one hit? I'm curious! As an aside, I don't do PID for any of my installs because in my instances the loadings vary wildly, and the feedback speed also has large variations. I tried it in the past and spent a lot of time tweaking things. I found that although I might get a small improvement in maintaining setpoint, what was actually happening was that the mechanicals involved were swinging wildly around to achieve it, thus wearing out far more quickly, which was a significant issue. For my stuff simple linearisations of outputs works best. But I am the first to admit that other people have far more knowledge about PID than I do! cheers, Aus
  7. In doing a quick mockup of something yesterday, I did it again, but picked it up almost immediately due to the metal surround "indicator". It gave me enough impetus to get into an Exp Adapter and have a close look at the PCB layout. I am likely mistaken due to not wanting to unsolder the socket, but to my eye it looks like the board is only double sided (ie no concealed links) and that there are only 5 of the pins in use. I did no meter checking at all, so perhaps there is some crucial linking of unused pins under the connector, but it looks like things could run using a standard 5 or 6 pin variant. I'm happy to be told my assumptions are incorrect. I also looked at the PLC end on 2 models, and they looked the same, but they were a lot more cluttered and perhaps the boards are multi-layer. But.....if my assumptions are correct.... the absolute best solution would be to change the PLC socket to a suitable mini-din 5 or 6 pin. It can't be changed to a 6 pin RJ as we'll be back to where we started as this size is in use for the normal com ports. If done, provide a simple M-F adapter with every PLC that has the new style port to ensure backwards compatibility. Given that every PLC I buy has the far more complex programming lead included, even if I don't want it and now have gazillions of them, this adapter would add a miniscule amount to the cost. PS/2 is/was a standard connection for years and worked fine. They can have locking pins if necessary. At the same time change the exp. lead to the correct male plug as well....and only do it at the PLC end. This would be a double whammy which would 1). give the cable orientation which would ensure the best earth location practice and 2). minimise retooling costs etc. Eventually as things get replaced the new arrangement would become the standard in use, ultimately meaning no need for the adapter. Please seriously consider doing this, guys! I know it's a fundamental change, but it's very annoying! cheers, Aus
  8. Hi Bill, Further to Chris's suggestion, I actually do it the other way around. I have the drum sequences set at the absolute maximum allowed for each step, and then adjust things downwards from there externally. This way the progression of the sequence is ensured if something's not right, or a setting is forgotten. Just a different way of looking at what you want to do. cheers, Aus
  9. Thanks all, for the suggestions....much appreciated. I had forgotten about the methods used in DataExport, I rarely use it. But it again means the use of a puter system that is either onsite dedicated, and hopefully always working correctly, or a remote that I setup to do auto wakeups and shutdowns etc. The setup can't involve any other computers that are in general ad hoc use. But my inner voice of experience is whispering that it just seems a bit too awkward and possibly unreliable, with the potential for a failure to go unnoticed until the data is needed but not available. I did also look at adding a 130-33-B1 like Flex suggests, but forgot to mention it, so thanks for the nudge, pal. It means a bit of work due to needing another small enclosure etc, but taking on board all the other issues against it being more expensive to start with, I feel it will ultimately be the easiest & best way to go. Thanks again for your time everyone, cheers, Aus
  10. Hi all, On my installs with single 230s, I am now needing to export large data tables automatically, or store the consecutive versions. The tables are purely logging and are set up to utilise as much memory as possible. The row number is increased by one every minute and then that row is updated with current readings. Once reaching the endpoint it zeroes and starts again. With all the parameters being logged, the table rollover occurs roughly every 36 hours. I've had a good hunt around, but can't find a way that I can store these, or send the entire table out, as an email attachment. I don't think what I need to do is possible with 230s. So....I am looking at either: 1). Changing the controllers, which will be a pain and costly, to something with microSD card onboard. But makes the storage and export easy. 2). Setup a small puter near the units running DDE to do much the same thing direct into an excel file at whatever timing suits. Would likely work ok, but is added complexity involving the puter definitely being on ok, and thus might not be as stable as a plc with SD. Reliability is paramount. 3). Send out an email often which can use as many characters as possible. But this will make things incredibly clumsy and hard to use, when trying to put it all into a graph that shows a 24 hour period. 4). Yes....I could log in every day and download the table, but this will be a pita and ultimately will cost me time and $. I don't think it possible to write a script to successfully get Visilogic to do this automatically...or should I say.... that's beyond my skills! And again, for me that means a dedicated puter needed. At present the similar logging I do with 130s, I download it every 50 days or so and once done ok, I clear things out of the SD. 5). I don't suppose there is an I/O module in the works that will let one add an SD? I can't be alone in my need and such an I/O can't be that hard to do. Or even better, a module that includes both SD and ethernet? 6). Any other bright idea someone else can think of? To me it looks like the best is going to be a controller change......bummer. cheers, Aus
  11. So.....I set up a local 130 to try, and I get exactly the same thing happening. I can get info, it shows the hand as green, but access via the hand then shows the connection failed message. Everything else works fine...but not quite the same result as Gabriel. Tried on all the android devices. Some gliche on getting all the info. I again note that there is not a delay in the message coming up that relates to timeouts and retries. It comes up within 2-3 seconds every time. All my Androids are on Avast, and I get the same result with it on or off. Suggestions please! cheers, Aus
  12. No go on the bigger phone either. 480 x 854 screen, Android 4.4.4. Exactly the same operations, where everything connects, except the link from the green hand. I have been trying both SIM data and wifi on both phones. I have been trying adjusting length of timeouts and retries etc and have noticed something curious. The "Connection to PLC failed" message seems to pop up after about 2 seconds, regardless of the number of timeouts or their length. I've now also tried it on a FullHD tablet, and exactly the same thing. And an edit in response to Gabriel's post below....all my tries are for a remote system....will try a same LAN situation when I can and advise results. Suggestions please! cheers, Aus
  13. Hi all, is there a minimum phone's screen size needed? Once my settings are input, checking says that the connection is ok, hand is green, I can get PLC System Info fine, but it refuses to connect for the main bit. I have only been trying this on my baby screen size phone at present, hence the question. Will try on my bigger one later. When I say "baby", it really is, due to bigger phones getting awkward in my often really cramped work environments. Screen is only 432 x 240. But it runs other things like remote videos etc. perfectly. cheers, Aus
  14. Hi again all, I run one of my laptops on 10 as a test case to try things and see whether Msoft have fixed issues. Today it has decided that it wants to update a lot of things, and has so far consumed 2.5Gb of my limited bandwidth. It is still going, and looks like it is getting an entire new version of 10 if I believe the update list, so it will likely be around 4Gb by day's end. I know I can set it to share things it downloads with other systems on my network once it gets them, and also tell it not to use "expensive" connections, but this isn't really the point. (and do I really trust Msoft to not use the "peer" setting to spread it further, even though I've told it not to? Nup!) The problem is the way it updates, based on the arrogant thinking that everyone has unlimited bandwidth and endless Gbs to play with. It has been a PITA having reduced speeds today, all because Msoft decrees that their needs TAKE PRIORITY. And I can't do much about it, short of disabling the connection, because it will resume things once I hook it back up. I have implemented throttling of the connection, but then it sits there for ages sulking, and still consuming lots of processor activity. This update inflexibility was, and still is, a major deal breaker for me. So 10 still gets my thumbs down at present. cheers, Aus
  15. Hi all, although this article is from EBM pushing their own barrow, it is worthwhile reading for those who may not know too much about EC motors. Section 3 gets to the bits you want to know about all the innate gains that will be made. They are much simpler to implement, cheaper to run and well worth considering if they are available for your installation, be it fans or whatever. All of mine are fan installations and have only had routine checking with ears, eyes and thermal camera, with no other work needed in the years they have all been in. http://www.ebmpapst.com.au/en/news/articles/technical_topic_of_the_month/2016_08_ec_vs_vsd/ec_vs_vsd.html?ct=t(Newsletter_4_2016) I have no affiliation with EBM and there are a host of other EC makers in the game, it's just that this arrived and I thought it of interest. cheers, Aus
  16. This has raised it's annoying, ugly head many times before, with various suggestions including one from you, Joe, wasn't it, of a lovely clunky connector? Given that stickers fall off blah blah, and the need for backwards compatibility, perhaps the best thing would be a part of the O/S that checks if there are weird things happening on the I/O connector that don't match up to what it is expecting. It could then throw up an appropriate error message on the screen and perhaps also force a stop. As the creators are going to pretty much have to stick with the same connectors doing different jobs, they should surely have something like this in place to permanently cover the silly things that happen in the real world. It can't be that hard an ask, given that fundamental things happen on the connector if in use. cheers, Aus
  17. Hi & thanks Tm, yep I thought of this one and I agree. But I don't have a correct unit to physically check but did look very carefully at the slots on the connector, (not the rounds) compared them to some of mine on other models, and thought that everything looked OK. (Surely Unitronics aren't inverting something this fundamental b/n different models?) But yeah, double check them again Rzasior. Unless it is a program issue, there is likely something really simple here that would be obvious if on site! I really hope this is it.....I should have mentioned to check it again. Keep hunting, Rzas! cheers, Aus
  18. Hi again, thanks for these. There is still a simple explanation for this somewhere, but it is hard to see without being there! The only thing that stands out in the photos is perhaps some earthing issues. I can't see them being the cause, but worth doing just in case. There is no earth at the PLC and perhaps the comms line is earthed at both ends if the blue lead going to the lower Turck earth IS an extension of the earth. Another thing is to check that there isn't some sort of residual crap in the push connector sockets that is preventing contact. I've assumed all along, here, that it is wiring, but perhaps there is a PLC program issue. My read of the Turck manual is that you have the address set to 2. No clash with the PLC? If you've used the Canopen example in Visi, the PLC is at 2. Haven't accidentally left it at that? If you haven't seen the example yet, have a good look at it's structure. That's all I can offer at present. Others here have far more experience than me with Canopen. cheers, Aus
  19. Hi again, I knew I wasn't going nuts!! A page did it to me again today, and I spent some time figuring it out. I'm using Firefox 47.0.1 on Win7 and the relevant areas disappear completely if you have zoomed in from normal, and the width of the window is not enlarged enough. Normally, zooming for me just affects the "overall" view or arrangement, but it is making the 3 red boxes that you have arrowed, magically disappear completely. Select the right window border and drag it in, let go and they disappear. Drag out, let go and back they come if you've gone far enough! It is something to do with the border width of these 3 items as the moment you go past, it happens. If you can't replicate this I can send you a small screen video if necessary. cheers, Aus
  20. Hi again, Yep...s/t not right somewhere. In relation to the above, in theory the Turck is set at 20Kb. Did you then run the PLC at all it's different baud rates to check if it connected at another speed? This is not clear from your answer. This is a long shot but s/t worth trying if you haven't done so already. Also, pls post a screen shot of your Com init settings, a pic of your connections at the Turck, and pls "label" the leads shown in the pic of the PLC connector. cheers, Aus
  21. Note: TEMPORARY UPGRADE TO WIN 10 Hi all, just bringing 10 into the limelight again, given the "freebie" expiry date is very soon. I'm sure many of you have done this already due to being way ahead of me in computers. A few months back Msoft (very quietly) changed the allowed procedure for migrating free to 10 from other valid Windows types. You can now do clean installs and apply the keys from your valid installation of 7 etc. Previously if you wanted a clean install you had to go through the tedious online upgrade path, get the system details authorised and recorded onto the Msoft systems once finished and then start again with the clean install. 10 works by remembering computer details in their systems and once it is there it sticks, as long as you don't change components (too much? drives?). I haven't looked yet, but apparently programs like Belarc will now pop up the same key for every 10 installation, even though you enter your numbers! As "progress" is always happening and eventually I will have to shift over to keep things secure, (and also because I am cheap!), I have temporarily loaded clean installs of 10 onto all my computers so that they are correctly registered in the Msoft vaults. You can check it is ok with a quick look in the Computer/Properties window and look for the "Windows is Activated" bits. Take screen shots that include all the details so that you can prove it later if necessary. I have then gone back to whatever I had on that puter....for now. Eventually when I feel ok about it, (and no doubt Msoft will constantly make it harder to remain "old") I'll shift over to constantly using 10. It is a little bit of dicking around copying and saving partitions etc, but in my case it is saving significant $s and well worth the time. The one clanger might be Msoft changing the rules yet again. Time will tell. Edit: I should mention that some people say that after upgrading, Msoft only allows 31 days from that time and then the 7 licence expires. Some of my 7's are well past that time and still going fine. Cheers, Aus
  22. Hi again, (on another sad day for the world) A very useful feature for me would be the ability to have a tick box present during the import subroutine process that lets you select whether or not to import all the user defined descriptions, or have them substituted with a "dummy". I often import code, but invariably due to each project I work on needing vastly different aspects, it is just not possible to utilise the same numbers and descriptions. But...and this is the crux of the ask....the ladder/routine construction is essentially the same. It would be great if the import process could simply go through all the elements and anything that is not system related is changed to a "dummy" number and the description is blanked. One would then only have to adjust labels and names to suit, but this would be far far easier than the current process which can get very confusing. This way it would only be a case of progressing through that routine/ladder, finding anything that is "dummy marked" (perhaps a #, ?) and adjusting things via a few mouse clicks to match up to the current program. cheers, Aus
  23. Hi Rzasior, Others may have suggestions I don't know about, but my immediate thoughts: It looks like you have covered things. I'm assuming the error led is not on with PLC disconnected and communication not trying. So time to check it all again! Easy things first as dumb errors easily missed! 560 reports a fault as well? Com init settings definitely OK? Earthing OK? Baud rate definitely the same? Polarity correct? Electrically checked all connections are ok? H&L correct at the Turck...not spaced apart over the terminal block, (although it shouldn't matter)? Tried altering the Turck address to one either side of what it is meant to be via the DIPs in case they have some strange numbering quirk? Also, although it shouldn't matter in the slightest, I always have all control gear running from the same phase. If again all ok but still the error, I would first be playing the "vary the baud rate" game. Set the Turck to the lowest it can go which is one above the 560's minimum of 10Kb, the info sheet I googled says 20Kb is lowest. Start the 560 at 10Kb and increase it a step at a time and see if the connection picks up. If it doesn't, vary the Turck and repeat. I would always be trying the slower speeds first. Maybe the Turck DIPS are not working ok. I don't know this particular unit, but I have had manuals where the information is incorrect and the DIPs are actually inverse in operation. Although the speed game is a pain, it is not that hard to do and I have sometimes picked up a dud connection with surprising implications. If still no go, I would be taking the PLC physically right next to the Turck and hook in with minimal cable length. If it works then that will help as it must be a cabling issue. If none of this helps then time for some more headscratching and input from someone here with more knowledge. cheers, Aus
  24. Hi again all, I'm still only on 9.7.55 /0 and still running Win 7. I have an issue that is not too significant, but over time it gets really annoying. During editing the name of an MI, say, in the description box in the Operands table list, the delete key stops working. I can only use backspace or mousework. It persists until I do a compile and save, then it works for a while then stops again. The only definite thing I have found is that it seems to come back OK after the save, but then stops again after use. Although it is minor, it is definitely a right PITA if you have to do lots of name changing, eg after a paste. None of my other programs do this. You merrily work away and then suddenly your editing goes wrong, and you have to change the way you do things again! I have tried, without luck, to find the pattern that starts it, but if anyone else has isolated it down please comment. It is one of those things you forget about until it crops up again and you can't quite remember everything that you've done beforehand. Whilst I'm on this issue, an associated one is that there seems to be a long delay/hiccouph in the associated text mouse click/double click selection process which sometimes leads to clicking not enough, or too much, or it brings up the Copy Paste box for no reason. cheers, Aus
  25. Just to clarify, using SB15 as the basis for this counter should be sufficient. If the input is stable the count reaches an upper limit, resets to 0 and starts again. But your logic might include resets to other than 0, up to the limit, for varying inputs. I strongly suggest making some sort of flow chart before you start writing code....often just doing it in Excel make things easy as you can move cells around as you add or subtract ideas. I put an individual needed action/event into each cell....not actually how I write the code....it is a sort of overview. cheers, Aus
×
×
  • Create New...