Ausman

The pdfs above are ok, but the issue with having such a manual is that things are constantly evolving. Hence Flex's valid comments. It becomes a minefield for Unitronics to constantly change manuals for every little change and thus have older manuals in use that might confuse people because they haven't updated to the very latest one that has some bit of crucial information. I remember bringing this up with Cara ages ago. We used to be able to download the "documentation library" as a zip, but this went by the wayside because of the continual changes issue. That said, I have zipped up the entire Manuals 9-2-0 folder that I have from said documentation. It includes 2 of the pdfs kratmel has linked to, and is passworded with my forum name. It is essential to remember that they are a bit old, and some info will be missing that can only be found by searching online. cheers, Aus VisiLogic Manuals 9-2-0.zip

Apart from your initial issue, if you don't have a spare PLC for an important process, you should have. Then you can use the spare to trial programming changes to at least get syntax and ladder work fundamentally correct. cheers, Aus

Just remember that it seems to go against the programming rules, because you repeat the use of the same system operands for each linearization. cheers, Aus

Kratmel and Flex have answered well. But FYI in your knowledge seeking, I sort of do what you've done with regards to a bolt in the axle. My methods let me easily use normal inputs for most standard motors. The trick is that you have to ensure the sensor is on or off for 180° of rotation. In my cases I always base my sensor position by first looking at the maximum rpm the relevant shaft is going to be doing. It is often not acceptable to have the sensor reading the head of a bolt that is perpendicular to the shaft eg a bolt screwed into a hub much like a locking grub screw. This is because of the speed of the bolt head going past the sensor, and the corresponding minimal on time that the plc will not register consistently. However, if you reposition the sensor so that it is inline with the shaft and reading the bolt thread where it enters the hub and positioned as close as possible to the shaft, the on time is vastly different and may work ok. eg a 1440rpm motor equals one rev every 41.6 ms. So if you divide that by half and definitely have the sensor on/off equally over 180°, then it will work ok. I don't do this sensing on the motor if it is driving something via a gear train or vbelts. I do it on the final driven shaft, (an extreme example would be the conveyor roller furthest from the drive) as this is a check that the actual process is occurring ok. I see so many people simply checking that a contactor is ON, assuming that that then makes the check correct. It doesn't, it only checks the motor is getting power, (sometimes not if the read is only on a separate contact set) and is a very common failing in machine design. But for motors doing direct drive that need the check, I mostly do the sensing by machining a simple cutout into the end of the rotor, or fitting an auxiliary hub with the same sort of 180° cutout. The sensor is then mounted to the fan housing and positioned so that it is pointing axially along the shaft with enough offset to read the 180° of metal accurately, which ensures the relative speed is very slow. Mechanical layout and logical thinking can get you past seemingly very hard issues and use much simpler methods. I actually dislike "Tech for Tech's sake". Cheers, Aus

I've also remembered another option. I converted a Honda trike to electric a while back and used parts from this supplier. Some of their controllers might make all of this much easier. cheers, Aus https://www.motiondynamics.com.au/12v-48v-dc-speed-control-single-direction-25a-pcb-model.html#

OK. I had a quick look at your program and the thing that immediately stands out to me is that you have far too much going on in each rung. Often you have set and reset in the same one. A favourite saying here is that "Unitronics doesn't charge for the number of rungs in use". So go through it all again, and split each and every "action" into another rung. Quite often crammed rungs do not behave as one would expect, as the plc interprets them differently to the user. Once you have cleaned it up, load it again but before doing any running also do an Initialise and Reset. That said, have you ensured that the encoder count is not varying when the motor is completely stopped? cheers, Aus

You're not somehow turning off the encoder reads when you stop the motor? So that the "inertia position" isn't being registered properly. I haven't looked at your program.....yet. cheers, Aus

I can't immediately find the specifications for limits, but the easy way to check is to use Hardware Configuration. Simply load up all the I/Os you want to use, and at the bottom of the window is the report on the capacity used. But I do recall some issues with this report in the past. Can someone also please remind me where the specs are squirrelled away! cheers, Aus

In the past I have heard of Gmail treating email differently if their algorithms decide that the addresses are somehow part of a known large-ish corporation/business. I believed that there was some sort of threshold involvement. I guess that is the downside to using a free service. The operator can do whatever they like with your info...even to the point of not doing anything with it if they think it is outside what they consider acceptable. Have you tried changing all the gmail addresses involved to something else...even brand new? cheers, Aus

My brain was nagging me on this, saying I had something else. After a few days of it running as a background process, I remembered what it was. In case it might help, I've attached a copy of a very simple circuit I made ages ago (look at that T-Rex going past) to run some 12v motors, that worked very well running just these types of motors at variable set speeds. It was controlled by a simple relay switching matrix, but these days you could easily change it to speed control via a digital pot run by the Samba. To run a number of digital pots you switch between serial lines using good quality mini relays with gold contacts. I've labelled the main lines, but your electronics guys could consider the full ramifications and any mods needed. cheers, Aus

Initially I'd actually log every single parameter change to a data table with a matching time. Or log all variable parameters to a data table every operation start. It all depends on how many variables change during the full operation. If the data tables are going to fill quickly, they can be shifted onto an SD for later viewing. This method would at least give you a starting point, by imitating those variables to see if you can consistently reproduce the error. cheers, Aus

With overnight pondering whilst asleep (thankyou brain), I actually think you need to change methods. A direct lift from the Jabsco sheet Kratmel refers to: I am all for doing unorthodox things, that is the way I have got around myriad problems over many years of designing lots of odd stuff. You have obviously been implementing this setup OK before. But I'd seriously consider changing the way you do it. I'd run the pumps at full speed and institute a variable valve flow system with a pressure bypass back to the respective holding tank. The pressure reliefs would be set equally so that the pumps don't get overworked. Both the valves could be easily controlled by an analogue signal which would be available on a different samba model, which would be set before starting both motors concurrently. Although this is still open loop, this method would likely give you much better flow control owing to consistency of mixing pressures. cheers, Aus

I actually think both those motors are not designed for variable speed. As Alex notes from the picture...reading the actual manual says for UP2.... WARNING: DUE TO THE EMI FILTER THE PUMP IS NOT SUITABLE FOR SWITCHING APPLICATIONS (PWM DRIVER) , which I interpret as "don't do this at all". You can likely run them as Alex says using a voltage regulator, but they may not physically like it, particularly the Jabsco as it is appears to be a swash plate mechanism. Also, getting something off the shelf made to work with 0-12V might be difficult. Most of the DC motor controllers I work with are 0-180V at least. How it was done beforehand I think needs to be exactly known. cheers, Aus

Are you SURE that it is variable speed? Or the wiring layout has been done correctly? It seems odd that it has an SSR connected to the supply unit, if it only needs a PWM signal to run that would normally come from the control system. Perhaps the SSRs are the main power switching, and there is another input available for the PWM that has been missed. This thought could possibly explain why the pumps suddenly ran, as the PWM may have crossed over the timing threshold so that the SSRs effectively stayed ON. This is especially the case if they are actually fixed speed. Perhaps you should post details of ALL the hardware in use. There is information missing here that appears to be crucial. cheers, Aus

Yes, it was. Does this mean that Joe spends hours in the cigar lab watching Sth Park? Kratmel, I haven't had any issues using it, wondering if it might be a language specific type thing? cheers, Aus

@NoamM just giving this/you a bump for Aleš. Aleš, if you don't hear anything soon, ask a direct question to the Creators: https://support.unitronics.com/index.php cheers, Aus

What do you mean by this? ON/OFF? Variable speed? With regards to one part of your program, do you know about Power Up values? Please note the screenshot below showing MI6 being assigned at Power Up the value you are storing to it. Tick the "power plug" and type the value. You can also do much the same in the Outputs view at the bottom of Visi. Perhaps 3 is a varying part of what you are trying to achieve.....hence the store when the rung is running. You are calling your output 0 as both a standard one and an "Immediate" type. Not necessary. Get rid of MB13 and the next rung. However, the rest of your ladderwork which relates to O 0 needs an answer to the very first questions. cheers, Aus

Before doing anything else, have you done an Initialise and Reset? Connection/Communication & OS/2nd Tab/bottom right. On any change that doesn't seem to work the way I think it should, I do this. It sometimes cures issues, and is likely good practice to do it on any change. But a note of caution if it is done to a "finished" system on site. Sometimes it might upset a process too much, so it may need to be delayed until it is OK. Particularly if your project uses large averaging in readings and hasn't got an inbuilt delay to accommodate this, or if it adjusts startup defaults through running. cheers, Aus

Zoran, have you seen these things? I note you say "no line of sight", but perhaps they could go on small poles? Or you could perhaps use simple long distance "remotes" as it is such a simple switching action. Can you do away completely with one plc (likely at the tank end) if you did this? cheers, Aus https://www.ui.com/airmax/nanobeam-ac-gen2/

Once finally installed, what is the physical distance between the 2? It sounds like it might be kms, but if it is only 10s of metres, it would be much easier to use Unican. You would have the need to buy 2 cards and cable, but then it doesn't need any other mucking around to get great comms. As well, once it is done, you can remove one of the ethernet cards as you can use the plc with the card to communicate to the other via the UniCan link. Even up to 100m might be an easier and simpler thing long term. cheers, Aus

Whilst we're on the colours subject, Visilogic lets you change colours but only applies them to some areas. eg Background doesn't change all backgrounds, like the explorer, as well. Why not? Pretty much for the same reason as above. I remember playing with color settings in the registry ages ago on this, but could never get the entire screen to do what I want. cheers, Aus

Glad it's solved. Just FYI, (I've said this before in other posts) but I have had instances where in trying to make things fast, I progressively lower Canbus comms times back to what seems to be working ok for an entire day, only for them to fall over a few days later. Adding just a few scans into my call times fixes the issue. I have found that for anything comms-wise, you need to allow a few scans for full buffer clearance, even though the system may say that it is finished. I surmised that the comms would eventually fall over due to a slow "build-up" in the buffer that eventually overloaded things. Or perhaps a glichey (?) read added in more numbers than normal? Or the data fairies waved their mean and nasty wand✨ at just the right time as they flew past going to Joe's place to share a cigar! cheers, Aus

But Joe, you forget that Modbus is "old" and not trendy. Only oldies (those humans greater than 25 years according to youngies) know about it and how much it is really used. 🙄 cheers, Aus

+ to Flex. I still roam around the menus and find stuff I didn't know. "How did I miss that before" is muttered quietly, whilst inwardly cursing for being such a dumbo! cheers, Aus

Edit... for some reason I had this as being a Unistream issue. As I have said before on the forum, I'm only a Vision man. But some thoughts that might be relevant...... Initially, I'm with Kratmel in that you may need more time. It could even be a buffer not clearing completely issue. As well, as an experiment, can you change the node numbers around to see what happens? Does the error still happen on 2 & 3, or follow the physical connection? This would indicate that the values are mainly correct and the inherent stream delays in being online is not showing them. cheers, Aus