Jump to content

Ausman

MVP 2017
  • Content count

    607
  • Joined

  • Last visited

  • Days Won

    41

Ausman last won the day on May 25

Ausman had the most liked content!

Community Reputation

82 Excellent

5 Followers

About Ausman

  • Rank
    UniGuru

Profile Information

  • Gender
    Not Telling
  • Interests
    Love/Hate waking up with a solution to a problem. Thanks brain....for not sleeping properly!

Recent Profile Visitors

4,938 profile views
  1. Isak's answer is correct and useful, but I don't know whether your IT guys would like it. And surely they can set up the Card Suite just on the puter you are going to use? As for continual access, I'd set up a cable link of some sort. The easiest will be to simply get the correct cable to go into the serial port on the PLC and use that to link to your puter. This way the card isn't constantly needing removal/reinsertion. The cable goes under various names RS232-CB1 or the MJ10-22-CS25 adapter name. And you'll need a good usb to 232 adapter on your puter to run it if you don't have a native 9 pin serial com port. Don't get a cheap no name one. Genuine Prolific. If you did the serial wiring and the IT guys aren't any help, get an older working W7 laptop as your dedicated intermediary device...preferably one with a com port to eliminate the need for a usb adapter. Put the Suite on it and ONLY use it for your card data transfer, with it not being hooked into the hospital system at all. You can then manipulate the UDTs on it at your leisure and save them to a stick for shifting onto the other systems. You should be able to pick up a suitable laptop very cheaply. cheers, Aus
  2. Hi Peter, If you do not have the program you might be in trouble. If the program was originally loaded in a certain way, you won't be able to upload it anyway...even with good comms. However.....for now we'll assume that it is able to be retrieved. Some thoughts and actions to try: 1) Go into info mode and navigate to the comms settings. Find what is being displayed for the 232 port 1 and ensure that your 232 settings are the same. Try again. If this doesn't work manipulate the numbers in info mode and try again. Being a 230, it's possible that com 2 might work as well, but this is age dependent. Try anyway using the above methods. 2) I have had annoying occasions where the standard programming cable and adapter doesn't work due to a fault that wasn't there last time! Check that you are a) using the correct cable and plug, and b) that it is ok. The adapter is MJ10-22-CS25 running on the standard 4 pin RJ. 3). Again in info mode, ensure that SB314 is OFF. If it is ON any PC access is blocked, but this is unlikely as not many people know about it. 4). Given my first comments about the program perhaps not being able to be uploaded anyway, and if it does turn out that the comms port has actually failed, you could purchase an ethernet card and fit it which will physically give the unit ethernet capability. The stumbling block here is something I don't know as I've never had to do it......can the port be initialised via info mode so that it can be used? Normally this is done via ladder code, but I think it would be ok to do it in info mode after adding the card. But I don't know for sure....I haven't got a unit to try this on. Someone else will surely chime in on this. If the ethernet access works, AND the program is set to be able to be read, then you are OK. Edit: All of this assumes that the PC's 232 stuff works correctly. Can you try it on something else to make sure? And perhaps slow the buffers down? Good luck. Cheers, Aus
  3. Hi Thomas, There is no way to do a simple mirror. However, my interpretation of your ask is that the extra IO is being added to the 1210 that is already there. In that case, you could consider running Remote Access or Remote Operator via a dedicated mini puter and touch screen, linked to the existing 1210. (Various methods of the connection available) This would/should give you all that you want, and would likely be cheaper anyway. cheers, Aus
  4. Ausman

    Upload Download the Unitronics way.

    No......they're just following the market leaders.....Unitronics! 😊 Aus Just noticed I'm the lucky 0x010x6f. Do I get my cookie now, Joe T?
  5. Hi Ben, it is all dependent on the connection method that is in use. There are a few answers to your question, right down to removing the card for direct file transfer, but it will be easiest if you fully describe the connection in use first. If the PLC is on the hospital's network, standalone, serial etc. cheers, Aus
  6. Ausman

    Upload Download the Unitronics way.

    Yeah yeah, we're all different and that's why humans are such a weird lot. I see the logic, JohnR, but I don't agree with it. My reference point is always the computer I'm working at. Hmmmmm..."has George's computer got a bigger disc and more RAM than mine? Hang on a minute whilst I figure out which way I've got to set the description box!!" One of the best methods I've seen is: Transfer program > PLC -> File... > File -> PLC... No room for error there! It also then opens subsections that let you choose how much detail you want to transfer. cheers, Aus
  7. Hmmm. It would seem that *.jpg might be the problem, like you suggest. Have you tried doing it without the image, but another csv etc? Can you have the image generated as a different type of file and see if that works? Again, an aside and another long shot, I often have jpgs that will not open in my main photo program. It says they are corrupt. But if I open them in paint and save them again, the problem goes away. I've never chased the cause as it is easily fixed....but it does occur and exists on jpgs coming from a variety of sources. So perhaps your jpg is one of these and there is some sort of check going on that is referring to the file type and waiting on certain info in the file that doesn't appear...hence the timeout. cheers, Aus
  8. Ensure all your comms settings are identical in the 232 side. And what happens if you "buffer" a delay between the sending of the two emails? ie Send them separately with a suitable time delay b/n them. The length of the delay time might need to be trial and errored to see how quickly it can happen...start with something long and gradually make it shorter. cheers, Aus
  9. I know this is likely NOT the answer, but I thought I'd throw it in just in case, and also as an aside of general information: I notice the plc's time is not correct. I have had a few instances where I have had troubles communicating b/n devices on a network because their RTCs are sitting on a time that is too far away from real time. They might be set to update automatically, but something goes wrong there and they either drift or get wrong time info. Don't ask me the technicalities, it's too far into overall networking architectures for me to grasp, but it does happen and seems to be related to more than an hour. You ensure time is correct on both ends and the issue and comms miraculously fix themselves. Magical/devious networking gremlins! cheers, Aus
  10. And an addition to my comments about "reset the count without upsetting things": during the reset simply discard all the items that are on the belt at the reset. Get a human to look at them if this tiny loss is not allowed, or else they are simply going back in the granulator. And your comment appears to still be based on using the raw encoder count, without my "reset the HS count and trigger a sub-count +1 addition" as your X pulses train. In all of this, I still think the likes of Kratmel's or my idea the best. But if you are still focussed on using the belt encoder, another way is to have each item's first sense initiate it's own count and at the same time reset the raw input count. You would then work the camera inspection on the correct number span being present that covers the way the caps fall around the belt. This wouldn't be too hard....the max qty on the belt at any time dictates how many "sub counts" needed that simply roll around in a FIFO way. That way you wouldn't have any issues with overflows etc at all. There are many ways of doing what you want, and I don't consider any of them too complex. You could even do it all again on another smaller belt that accepts the first one's output in a far more uniform pattern, given the importance of no errors. cheers, Aus
  11. Somewhere in the process it wouldn't be too hard to reset the count without upsetting things too much. However...... Perhaps the best solution is to not use the belt encoder at all. Instead do a rolling actual count of how many caps are on the belt from the first sensing point, and physically add a sensor at the reject blowoff which ties in to how many items are "active" at that time and whether they are good or bad. Depending on the max quantity at one time you can likely use shift registers for this quite easily. Would be more accurate anyway, as it is item triggered, not theoretical location. cheers, Aus
  12. If you have the "same" problem, have you tried the solutions listed here in the topic? cheers, Aus
  13. That's a good idea, Joe. Hadn't ever thought of applying the 1.25 to actual inputs, have always used it for my quick counters. And I'm also assuming your "1.25 seconds" actually means "1.25ms" And can you pls clarify on the "expansion is scan time" comment. I have always thought expansion DI/Os were scan time, but analogue I/Os are a bit longer. cheers, Aus
  14. The simple answer is Yes. But...... In instances like this the main thing is how often the rise/fall of the input occurs per second. You weigh that up against the longest scan time your program is going to do and whether it will be possible for the input's change of state to alter twice in that scan time relationship. The one sometimes tricky factor is when you have a varying speed of change input, this needs careful looking at. But in your case I assume that the Hz will be fairly well spread over the second/time, and your program is not taking longer than a few ms per scan, hence the Yes. cheers, Aus
  15. Joe has clarified what I meant...but didn't actually write when I said this: I meant "Use the store function to copy the encoder value at the moment the item is captured, and then do the maths." (Sometimes my brain doesn't fully transpose all my thoughts into keyboard tapping!) And on this question, you can do it by having a count with the +1 triggered by the "every X pulses" count on the encoder being reset. ie if the encoder count has reached 100, it is reset, and as part of this reset your "user count" has 1 added to it. In this case a 100 to 1 ratio. cheers, Aus
×