LoganS

I was wondering if those would be required to do this. I will let my IT support know that these tools are at their disposal as well. Thanks Only reason Im trying to stay with visilogic is because I know it already. Im sure someday I will have to make the leap but so far havent needed to.

txt file source would be the company's part database it would be coming from the company server that will be on the same network as the PLC I would imagine the basic sequence of events will be something like: User scans bar code which searches database for the text file for the part number that was scanned. The IT system will have some scripting/code to then send this txt file (or portions of it) to the controllers IP address. The information from this sting of text will populate some different MI in the ladder to set parameters for the machine. Hope this helps, thanks

Haha well fortunately I fall just over that 25 year age restriction and use and love modbus. I will ask the IT guy about coding something to feed me modbus frames. I guess i was just hesitant to ask him to do more because of my short comings/lack of knowledge on the TCP side of things. I guess ill ask then just to try and undertand and learn then- what are some of the tools in visilogic that could be used to handle data on the TCP/IP layer rather than converting down to an application layer protocol like modbus? I see there are some TCP RAW and UDP RAW function blocks but the examples and info in the manuals is very simplistic and vague. There is also an SNMP protocol that is way out of my wheel house. Anyone have any insight or resources on these? Thanks

i guess im just confused how i get modbus messages out of a server? is this easier than im thinking it is. I assumed i would have to pull in raw tcp or udp somehow or else have an intermediate device translate to modbus

Im presented a situation where a customer has a machine that pulls its parameters from texts files on the company server when the bar code reader scans the part number on a job ticket. The bar code is just pointing to the text file of the associated part number. This txt file contains all of the parameters for the part. The existing system is a laser marker and it is already set up to pull all the information it needs from the text file. I have been tasked with integrating a robot to automate the loading and unloading of the machine, which I am comfortable with. For the machine to function how they want it to the robot and peripheral fixturing will have to self adjust to accommodate the different parts, and again, I am comfortable with handling all of this once the data is in the PLC . What I am not familiar/comfortable with is the "IT data"-to-PLC side of things. What is needed on my end to pull in this information from a text file? I have at my disposal a competent IT person at the customer site that says he can do any scripting that I need to get the data isolated if need be but where I am lost is what do I need to have on my end and what do I need to ask him to do? Can my vision controller handle scanning this hole txt file and then parsing the data I need? How do i request to pull in this info from the text file? Is there a max string length that I can pull in etc etc? Manual data entry is not an option There are over 10k part numbers so having all of that already in the plc is probably not an option Communications will be ethernet. At barcode scan, paramters will need to be loaded, machine adjusts, then cycle start Any help appreciated thanks

here is my code. It is working well. Ended up going the data table route as I couldn't wrap my head around any other way... I didnt see how a shift register would have worked as it is sort of a 3d array of data not just shifting bits. Anyways take a look and offer any suggestions if you wish. Basic flow is this: Camera trigger time stamps 2.5ms counter value to data table in the row designated by a pointer integer (power up zero) desired time delay is added to this value and sent to the set point column in same row. (200 gives me 500ms) judgment condition Boolean is sent to same row in 3rd column after the Ready signal come back to its high state if there if OK input is high. table lookup utility is constantly sniffing row 0 for current time = setpoint, and when it does, the physical output tied to air valve is opened if there is a 1 in the judgement column. after the window looking for judgement=1 executes , row zero is deleted and everything shifts up repeat I just need to add a few interlocks to it for faults and setup modes and the likes, as well as add a duplicate with another set of operands and data table for the second camera. but other than that the code is doing what I need it to. I estimate my time synchronization is around +/- 7ms. (2.5ms counter as timer and a 2-3 ms scan time) Will be doing more testing for bugs as well. Zero bad product being accepted is tolerated so It needs to fail in a safe manner if its going to. -Logan vision system #2_3_17_20_redacted.vlp

It is not consistent. The parts are metered out from a vibratory feed bowl. The time between trigger and output is also variable, hence why i am trying to do this.

It sounds like combining the two solutions above is what is needed... The example provided by kratmel the guy used an encoder... I can logically create this by using the interrupt proposed by Ausman and tie this DW from the interrupt counter, correlate it to my commanded frequency on the frequency drive and have pretty tight control over position. To keep things simple i will hold frequency constant until the code is working and just use the interupt as a timer but you can see where I am going with this.. Im going to try adn get some logic down and I will post as I am sure there will be issues. My favorite quote in the thread from Kratmel when Joe Tauser said "This one's not as easy as it sounds." lol Thanks

Would it be possible to log time stamp at every trigger, add 500 ms, then delete from table when output is sent?

Thanks Ausman, I read the topic and though it was insightful to the function of the interrupt Im not really seeing how this would be useful in my application. Perhaps I did a poor job explaining or perhaps my brain just has not made the connection yet. Not sure if this helps, but put simply I am basically trying to have this judgement condition operate with a 500ms lag. Sort of like a lagging conversation over the phone: all information retained but it comes thru at a delay. Does this make any sense?

I'm ashamed to admit that I cannot figure this out. Probably over thinking it, or maybe it is actually difficult. What I need to do is time an output to go off after 500ms of receiving a trigger input IF the controller ALSO gets an OK signal after the trigger input. I need to be able to receive these trigger inputs and OK signals in 50ms cycles. So basically I will get 10 triggers before my first output if the system is running at full capacity. Since program time is variable the output for OK is dependent on that; I also have a READY signal available that is high when trigger is low and system is not processing. The OK would output immediately after rising edge of ready. A NG judgement will be assumed for a trigger with no OK input. See timing chart attached, trig one is OK and trig 2 is NG. Essentially I need to recreate the trigger pulse train for the instances with an associated OK at a 500 ms delay I was considering throwing the binary bits into a data table then pulling them back out after 500ms removing the oldest entry each time but even that I cant fully think thru/ wonder if there is a simpler way. Application details- This is a vision system to a samba 43 and the vision system sends its judgement output when the program is done executing. Some programs are 30ms some are 400ms depending on camera resolution, program complexity etc. The parts are traveling down a conveyor belt at a set speed so the output timing determines how far the part has traveled since the trigger, hence why i want to hold that constant at 500 ms. We are blowing the parts off the line with air if they are OK. Surely someone has done something similar to this.. Any advice appreciated, thanks

FYI had to roll back my program to the older, slower version. After a couple of hours the remote IO module would glitch out and stop responding giving no watch dog errors or anything. Swapped all hardware with new to no avail. Reverting program made the problem go away. Makes no sense but figured I would share.

I was able to almost double my performance using the code below. Thought i would share for anyone else that may find this post down the road. I am getting about a 22ms round trip to read an input and update an output. I was around 45ms before. This may still not be technically proper the way I am setting and resetting coils after the FB but it is working and now it is not timer based so theoretically executing as fast as PLC scan-data transmission-device scan will allow. application details: my plc scan is 2 ms for this application, I am reading 16 inputs and writing 8 outputs over standard CAT5 cable.

Could you show me a code snippet of how you are initiating the read write FB's continuoulsy every scan?? All of the examples in Uni are of someone pushing an HMI button and sending the data. I also couldnt find any examples online... I cant believe that continuously scanning IO slices as fast as possible isnt a question more people are asking. I guess maybe I'm just the only one struggling with it, or like you said, maybe the device is just slow. I doubt that however, im sure its some setting I have

mb 30 stays on once the remote IO is online. Since this a remote IO device I want to continuouly read the inputs and write the outputs as fast as possible with out missing packets and with predictable behaviour. I have this currently working with a 20ms timer for read and write making for a 45 ms round trip. I am just trying to improve the performance to maybe a 10 ms (which in my application is about 8 PLC scans which I thought was easily doable) maybe not tho. Im sure it would work with 100ms delay, as I currently have it working with 2oms delay Attached is a capture of the logic I built to get the read right to continuoulsy execute. I started with a high number and reduced until the behaviour of the read writes became erratic and landed at 20ms. My whole reason for posting is to see If I can do better than 20ms. As you can see, once socket 2 is online, there is a 1 second delay, then "rx tx start" is latched. Then there is what I intended to be a standard PLC flasher logic (maybe this is where I went wrong?). This flasher sequence controls "IO read write". "IO read write" is then feeding the read write bit via a direct contact to the read, and an inverted contact to the write. These just turn on the "request to read" and "request to write coils" and the rising edge of each is what kicks off the respective modbus FB's. This works well IF 20 ms is the fastest I can go. If there is something fundamentally wrong with this preventing me from going faster, I would like to hear.