Michael_Burgess

cheers dide only thing that i've noticed now is when I hit the stop button there's quite often a lag of about 4-5 seconds. Ideally it's meant to be an emergency stop - it halts all the parallel processes then the next part of the sequence writes zeros to all the ports to halt all activity. It was quick a while back, but now it's got a lag in it - down to those 'wait' functions you reckon?

I'm no pro by any means, but surely in any language you shouldn't pass around data you don't need to? I must say, since I discovered LV2 globals they're a godsend!

sorted! pretty chuffed me thinks Download File:post-947-1112376890.zip

I'm assuming you mean along these sort of lines Michael? Only issue now is for some reason the output has stopped working in certain areas - if I do highlight execution things appear to happen - will my input VI cause issues do you think? The Chain Conveyor works, but the Sort Area is not firing the Solenoid - neither does the Assembly Area, but the Conveyor Area starts up the conveyor belt when it thinks there's both a peg and ring in the system (so this proves the Sort Area is correctly identifying them, just not firing the solenoid to sort the rings) and the Reject Area solenoid is firing too - so just seems to be the sort and assembly are playing up - odd - going to keep trying to work this out, but can you see anything that i've done in my labview naivety? My Logfile is all as it should be - so the SubVIs at least think they're doing what they should be - just the issue with the output - probably a schoolboy error on my part!!!! I've not changed the way that output writer works - odd! Can see a difference though - I've added a delay where I need it and the reject area solenoid still fires immediately when a reject object is in front of it - I'm just not too sure if my queues are working properly or not Any ideas dude? Cheers *EDIT* I seem to have sorted the problem by putting the index array functions for the input outside the while loop - that was the only difference between them and the reject area - thought I'd give it a shot - worked! When the index array was inside it seemed to look like it was iterating twice on the loop, so the outwriter value to fire the solenoid of '1' would be moved to the edge of the while loop, then it would iterate again, now the firing case was false, so a value of '0' overwrote the '1' waiting and then the loop seemed to release the new value of '0' to the outwriter, thus cancelling the original request to fire the solenoid! Weird! The only issue now is that sometimes if I halt the program with my Stop button I get an error from the 'pegqueue' or 'ringqueue' LV2 global I made saying there is a missing parameter - I think this is only when the queue is empty. *EDIT* Seem to have fixed the queue problem by turning off automatic error handling - although it's not ideal, handling errors is not really critical here - the hardware i'm working with has limited facilities in that respect *EDIT* put clusters in now to neaten it up slightly! Does my approach RE the queues look ok to you? You evidently know your stuff *EDIT* test tomorrow and I may well be done, give or take some frilly HCI extras long post anyone?

At present I've been using 4 queues to pass data around - 1 for identifying the peg number, 1 for the ring number, 1 for the first inspection area and 1 for the final inspection area. Is it still possible to use just 4 queues? If I obtain a queue outside of the parallel loops, then feed this into the six seperate loops, will the queues be passed around ok? I've got a feeling the queues won't run properly as one of the loops will effectively trap it until it finishes executing, which is when the program terminates? I've had trouble in the past with queues and multiple loops so not overly sure - going to back-up my work now and have a hack at it, but got a feeling it'll go pear shaped lol!

ah one more niggle i've seen when I profile the system using Michael's output method, it runs brilliantly - nice and quickly, lots of iterations and reacts more than quick enough to input in the assembly area though, I have to delay it somehow - basically when the sort area fires a plastic ring down the chute, if there's no already a plastic ring in the assembly hopper, open a solenoid to let this newly fired ring into the hopper - so firstly, I have to add a delay in the assembly area of about 300ms to let the ring slide down the chute before it opens - and I also have to add a delay of about 450ms before it shuts the solenoid so the ring drops down properly. this makes assembly perfect BUT completely slows down the program and reaction to input becomes slow generally - I can see from the profiling tool that the subsections iterate about 1/3 as quickly with these delays in - using the 'wait (ms)' node. hmmmmmmmm! if there a way to put a delay in without making the rest of the program suffer as a result? cheers

seems to be running pretty smoothly cheers Michael I've got a niggle with some Boolean Logic This attached VI basically picks up if a passing object is metal or plastic (assuming nothing of any other type has been placed on the conveyor) - I can do the metal identification easy, but for the plastic one I have a niggle - it works most of the time - but when the conveyor is moving quickly, it picks up the metal objects as both 'reject' (or plastic) and 'metal' So my code must nearly by right, just a slight issue in it - not really sure how to do a latch Boolean logic isn't my strong point - it's really bugging me!

well, top bloke! going to test drive that after the weekend but thank you very much for your help! RE the File I/O, it was still slightly iffy before I added that - I need to log everything that happens, in the order it does - I suppose a queue could do that, passing the queue to one subVI handling file I/O? Hmmmmm, that could work! I did wonder about the number of SubVIs - it seemed like it should be ok! thanks man

Ah Louis, what I thought may happen, has happened. Because i've got so many SubVIs and nested SubVIs (I need them really as i'm using Labview 2 style globals to manage counters and common repeating tasks - i'm assuming that's a good approach?) the performance suffers - now i've moved that into the main loop and removed the other, the output is occuring, but there's a lag and it's sometimes missing its deadlines. That was why I chose 2 loops - I might try and change the output to a queue maybe, to queue up all output, so nothing is missed - it's all a bit tricky!

That's actually a very good point Louis! I'm still adjusting to Labview, coming from a C programming background mainly, so the temptation to use local variables is far too great, when in actual fact the wire is labview's version of the local variable if i'm thinking along the right lines? I'm trying that out now! I can probably get my head round any timing niggles that occur this way! Fingers crossed - cheers

Just hit a new issue that I feared may rear its ugly head! If you look at Run.vi, you can see that each section in the bottom parallel process (while loop) passes an output value, which is then passed by local variable to the other parallel process (while loop), where it is output to the card. This output requires an 8-bit unsigned integer (the output port is 8-bit) between 0 and 15 (only the bottom 4 bits of the 8-bits are used, with values 8, 4, 2 & 1). I have identified the necessary binary value for each component (motor, solenoid etc) and this value being passed from each section will fire the necessary component when passed to the other parallel structure. The issue i'm now encountering, is that the top loop sometimes never gets the output value for the sporadic outputs, as the value I pass for output is part of a sequence diagram within a case structure (in the Assembly area for instance) and the sequence diagram executes so quickly, then the case becomes false and the output value will be set to 0 again for that section, meaning the top loop never received the output value. Can anyone think of an efficient way to ensure that any output I need definitely reaches the top loop? Bear in mind I need to output differing values constantly - it may just need 2 motors on at some point, then it will need to fire a solenoid, so it will still need to run the motors AND fire the new solenoid, then another solenoid may need activating at a similar time. Basically, a way to ensure that any 4-bit combination I need between 0 and 15 is output when I request it and it doesn't get overlooked. Cheers guys

in that attached image, the top loop which contains 'input' as a sub-VI doesn't appear to be working this subVI reads from port B, the input port I have tried putting input in a while loop to constantly read from the port, but the usual happens - as the loop is running, it will not release the input data to the notifier. I really am at the end of my tether with this - getting nowhere work mounting up - arggggggggggh!

Cheers Michael, i'll have a read of that in the morning

Hi Louis - thanks for that suggestion - I am attempting to use queues and notifiers. Basically, Port B on a 3x8-bit port interface card provides input. This is given as a figure between 0 and 255. Differing values = differing combination of sensors, so I need to pass the current input value to each section (I have identified 6 or 7 subsystems, each of which I will house in their own while loop) and act accordingly. I am using 2 queues to identify the number of pegs and rings in the system (the application is to control a production line simulation that sorts and assembles rings onto pegs and checks for correct assembly, rejecting the incorrect ones. I am also using a notifier to pass the Port B input value around the system. Here is a screenshot of what i've been working on tonight - I can't test it until I get into University tomorrow - best head to bed - it's 02:25 here in the UK! Cheers guys

also just had this thought the input data will be changing very often - it could theoretically change a few times in a second I've just seen that there's a preview queue function, so I could theoretically have all loops preview the front of the queue and when they have done so, flag this, then have a loop that checks when all loops have checked the head and dequeue's the head if they have hmmmmmmmmm - a bit stuck here - I think queues may be too advanced for the problem at hand