Jump to content

Ausman

MVP 2017
  • Content Count

    1,397
  • Joined

  • Last visited

  • Days Won

    75

Everything posted by Ausman

  1. OK Matt. We've all been there at some stage. I suggest that you learn a little about "bootlace pins" and their proper crimpers. cheers, Aus
  2. Have you missed powering the module itself? cheers, Aus
  3. Have you run your meter over all the power and earth lines? Modules are commoned to the supplies providing the sensors? cheers, Aus
  4. You could always go outside the square and use a cheap load cell and transducer to measure the weight of your pre-intoxicater. Of course you have to allow for all the other associated bits hanging off/attached to the kettle, but the end result should be a completely accurate volume level. No cleaning or other hassles. No point having a nice home brew if it kills you. Not being a typical Aussie I don't know how much beer changes weight as it brews. I do know that too much beer increases weight somewhere else! 🍺 I think I developed a dislike for the stuff after having to go into pubs first thing the next morning to fix things, and reeling at the pong.....(smell for you non-aussies). cheers, Aus
  5. Maybe Nikola might respond to a PM? In line with Flex's response above, wondering if doing an initialise and reset might cure things? But this will mean the user needs to get into info mode if you can't do it remotely. If remote access is possible but not currently in place, and it is a long way away, consider sending the user some components to get you online? Or try sending an SD with the program for them to transfer, before ship/replace? I'm wondering whether it might be some innate thing in the display itself, that perhaps an internal connection jiggle might cure. But all of these need basic skills. cheers, Aus
  6. I thought that was you, Joe. ☺️ I still don't quite understand why my 2nd & 3rd sentences aren't an easily done, onboard solution. Using row 0 which Kratmel spoke of is part of this. Machine has enough to get going by using row 0, can be tailored to suit, can easily bring up any of the saved tailoring by day or week depending on frequency of save, and consequently replace a change that isn't working with one that is known to be good. The save frequency could be when a certain number of parameters changed reaches a "new record needs to be done" amount. Write the table to SD when appropriate, which then lets the system be easily recovered from a battery failure. Isn't the primary aim the KISS principle? cheers, Aus
  7. Yes. πŸ˜€ Getting serious (πŸ€“) now, why? Is it to have a program that tailors it's parameters from a basic set of numbers on startup? And rebooting loses all the tailored amounts? In that case wouldn't normal memory retention be OK? However, I can see that if you need basic parameters to get things going initially, perhaps a "manual initiate" screen that loads all the relevant operands with the basics. After doing that the program can run and then if it has power failure the normal retention will maintain things. Or add them all into an indexed data table that is periodically saved? So that it can be recalled, perhaps by the "manual initiate" screen? This way would get around battery failure as well. cheers, Aus
  8. Logan, I thought about entering into this topic with some personal observations, but decided not to as it was running along quite well. I've had instances of something similar when using a serial modbus line with quite a few slaves. I'd lower the speed b/n calls until it became unstable, then back it off (hmmm "raise it up"?) until it all ran ok. Would do other jobs around the site for the day and it would still be going fine on leaving. A few days later it would fall over, and the cure was a slight increase in delay times. I can only theorise that my initial time was running very close to not allowing the buffer to clear properly, and eventually the accumulated(ing) stuff reached a tipping point where it cracked the poops. All the info being derived was always the same amount of transmission. Whether this can happen using TCP I don't know, but it does sound awfully familiar. For me, buffers in Unitronics land sometimes pose issues that have to be allowed for. cheers, Aus
  9. Kratmel has just replied whilst I'm writing this! I've had a quick look at the program and one glaring error is rung 2 where you have MB2 shown as a coil, it should be an inverted contact . There are other things that are a waste of space with what is shown. MB1 is not really necessary the way you have things running. I get the impression that PLC logic is new to you and perhaps a bit of research into how the different elements work would not go astray. The help files will cover all of this learning curve. The other thing to remember is that even though the system may say that serial actions are finished, I always allow at least a few scans for the buffer to fully clear. You may run into issues if you don't do this. A simple counter loop incrementing on each scan that runs after the system says it is finished is the easy way to set this up, where it resets to 0 once reaching the number that consistently supplies good serial operations. The 0 reset is also the trigger to do another serial action. Anyway, have a look at Kratmel's efforts. cheers, Aus
  10. On the 16-16, have you got the input wiring configuration correct for using either NPN or PNP? Is it matched to the setting in Hardware Setting of the Module, in Visilogic? All other wiring correctly done and linked to the D16-R16 according to the various install pdfs? Confirm there is no snap-in on the 1210. Please elaborate on your "96 interface relays". cheers, Aus
  11. This is one of the reasons I made this Excel sheet: http://forum.unitronics.com/topic/3540-linearization-calculator-for-all/ For anything analogue that is showing "linear" input behaviour, but is slightly "off" in readings, the above sheet lets you easily adjust numbers to suit your needs by changing appropriate numbers and seeing final output very easily so that you can get things almost perfect. Sometimes I have used a few linearizations in a series type setup, where the input is not completely linear but has slight changes to the curve over the input range. In "Utopia" land at Universities, everything is exactly as specified. Sadly, in the real world, slight discrepancies are common place and have to be allowed for. Anything with a large discrepancy indicates a problem. cheers, Aus
  12. HI Dragec, a quick look at this is all I could do and perhaps the magic thing that you might not have learnt yet is Set/Reset on MBs. You can Set a MB to stay on until you Reset it. The other thing to keep in mind is that SD card actions take far longer than you might be expecting. You need to allow time for something to finish by having logic in your program that acts according to the various flags that turn on/off during different SD actions. No doubt others on the forum will chime in soon explaining that you should get rid of all your previous programming notions. That way you won't break your brain, just learn new stuff! cheers, Aus
  13. Kratmel, I'm with Joe on it being a bit hard, and agree with his direction of travel method. But I will throw in something I often have to do with the stuff I make. I'm assuming that there is an inbuilt ramp time in the process. Even if there isn't, my method is to write a program that triggers start and stop actions based on accurately done time intervals. The motion is set to it's native start point. At time zero you send a start message, and then at the end of your first progressively increasing time period you send a stop. The plc then records the absolute movement result in a table matched to the time period. The physical motion is then reset to the native start point and the process begins again using a slightly higher time period. Once you have done this for the entire time range you have dictated in your "learning program", you then do it backwards, with the start point being the uppermost native limit point. If needed, the same thing can be done using a different native start point, in case the physical action is not direct but "leveraged", which might mean a different amount of time to travel a given distance if the start location is not the native end point. Done correctly, this method lets you build a database that gives a good idea of how long a time is going to be needed between start and stop signals to travel a certain distance. It is all done by the plc without any human involvement. Trust me....doing this manually turns into a nightmare!!! Having the subsequent database makes it very easy to adjust things to be very close to your aims. Fine tuning can be done if needed by actual trial and error, which is made so much easier by your times being based on something that has been done in reality. Often I don't need to adjust anything at all, it is spot on. The problems with the method are that the travel speeds may change slightly over time, someone might fiddle with the drive's parameters or trim pots get "old and noisy", different loads etc. To this end you can redo the learning cycle periodically and see if there are any differences. These differences can be automatically applied to the normal program if you want to do clever maths that adjusts MIs etc where relevant. cheers, Aus
  14. For clarity of numbers, have a look at my calculator from here: http://forum.unitronics.com/topic/3540-linearization-calculator-for-all/ Play with numbers as appropriate and watch the result. The idea for ramping is to relate the time elapsed to the desired temperature at that elapsed time, and then control heaters appropriately to match the desired temp. cheers, Aus
  15. Dumb question time. Have you made sure that all firmware versions etc on the new plc is identical to the old? Programming the new in the same Visi version as the old? (Even though that shouldn't make a difference, but who knows!) If that isn't the trick, run two instances of Visi side by side and then do right click Find on your different elements. The subsequent list might show up an error or number of instances difference between the two. If you have used the Replace operand facility, make sure that you have not overwritten something crucial in your new destination. Visi will just plonk any vector you specify over the top of existing stuff. Because of this, I only use Replace very carefully, and do multiple saves under a FIFO naming system so that I can go back even just a few minutes ago. cheers, Aus
  16. Let me see now. What does this ON button thingamijigger do? !!!!!!! πŸ˜€ cheers, Aus
  17. By this I mean that the inductive doesn't necessarily need to actually be on the arm. Most of the time you can find a convenient bolt head or similar within the drive train that can be used very easily by adjusting the sensor's mounting point to be in exactly the correct location. If the bolt etc is mechanically connected to the arm then it isn't going to vary! Although not applicable to this, in some instances where all else was not possible, I have even machined slots in motor shafts at the fan end to enable a definite read that the motor is actually turning correctly, an inductive picks this up very easily. Or put a leg on the arm that will prevent the scatter. Busy at present....just a quick drop in during morning start.....wait! cheers, Aus
  18. Put an inductive in a suitable location to sense when the arm is going to affect the beam. Disable the reading for that period. Alternatively, when the laser returns the reading it should get as constants with perhaps a given range from when the arm is in the way, set the program to ignore anything near those values. (Much like Bob suggested.) (This topic has also reminded me I never got around to showing to the world my "simple" averaging example, which I should try to find time to do!) cheers, Aus
  19. + to all of Simon's. As well, is your 24V really 24V? Sensor on the same supply? etc. I know Fluke are great, but have you done the same test on something else to check? cheers, Aus
  20. Erebo, sorry, I can't give this time for the next few days at least. Someone else chime in? That said, did you actually do the online manipulation like I suggested. Your "still having problems" doesn't really answer the question. cheers, Aus
  21. Joseodar, please check this post, and topic. It might help. cheers, Aus
  22. John, I find it curious that many types are giving you trouble. I just see a link between "power meter" and "drops". Is the chain done correctly with excellent shielding? Unshielded sections not near power lines? As well, are all devices set for comms correctly, with no clashing IDs? All terminations and resistors located/set/programmed properly? I know these are basics, but often something in a big chain is easily overlooked, or doesn't properly retain a change as expected, and a conflict arises. Many modbus things I work with annoyingly need a special program to change IDs and retain the change in the initial stages. Once done properly, normal access is easy. Of course, the basics of your question are also valid. But the coincidences are high, hence the questions. cheers, Aus
  23. arzel, click on the .ulpr link at the bottom of Liranaftali's post and it will act just like a download link. You must be registered and online on the forum to do this. cheers, Aus
  24. Hi dtwbb, please do not do multiple posts about the same issue. It just gets confusing on the forum. In future, please just do one post describing all your needs and observations, if desirable as a follow on in a topic, and include links to what you have found elsewhere if useful. I have left all of your current ones up for this time only. Please also remember that posts do not get shown until moderator approval occurs, which can be some hours if all the volunteers on this forum are not active. cheers, Aus
  25. Hi erebo, check the operation by going online first and manually manipulating the analog output. If you have indeed got everything set for using 0-4095 0-10V output correctly, and also everything set ok at the drive end, manually entering a value of 1020 should have your motor's reducer output somewhere close to 18.75 rpm. 2040 should be around 75/2 = 37.5rpm. etc. If this isn't the case then something is physically wrong with your setup. If it works ok, I'd be changing your maths around a bit, but that's the next explain. cheers, Aus
Γ—
Γ—
  • Create New...