Pulse Machine Monitoring

[jwvt88]

Hey guys, not sure if any of you are familiar with Lemoines Pulse Machine Monitoring?

I'm looking for help coming up with a solution. When I started here, no one was taking this software very seriously. As a programmer, we have some pulse information in our post that we needed to edit the job name, op #, and # of parts per operation. However we were all filling in this information differently. Apparently within the software that the scheduling guy uses, he can't reallocate jobs under a different name. I've never used the software on his end, but we had a meeting about it and basically if we even have an extra space in the macro then it creates a different "job" for everything.  Here's an example:

(PULSE PART= RCO46842-13  OPERATION=OP3 QTY=1 )

would create a separate job from

(PULSE PART= RCO46842-13   OPERATION=OP3 QTY=1 )

This has created a complete nightmare for us. Seems like it would be easy enough to implement standards for this, however we get busy and things get missed, fat fingered, sometimes someone from an off shift comes in to make a change to a program. To my boss, this is terribly unacceptable and he doesn't seem to understand how easy it is to make a mistake with this. I'm under the impression that well before I started(or any current programmer worked here), that when this was initially setup that it was setup incorrectly. If you could see some of the MC files we still have to deal with from the previous programmers, you would understand. Completely lazy, every level unlabelled, every job is programmed in TOP TOP TOP for every op, and some of the previous programmers even had separate files saved for every individual op, hand editing posts for almost every simple thing(THD, coolant, taps all at zero, G61.1).

Does anyone have experience with this software? What would you do in this situation? Do we need to start from scratch and redo everything? Do we need all new posts? We have not had any formal MC training, is there a way to setup in MC so it auto fills out the same exact information every time it is posted without us hand editing this? We recently changed some of our posts so it automatically inputs the file name after the PART=, but the scheduling guy doesn't want any rev label or anything, so we still have to edit it. I don't really want to go through resaving every old job under a different name, as we have files from 10+ years ago still running, and when they need something changed, the setup sheets still reference the filepath names. Although, we do need all new setup sheets done, I simply don't have the time to redo 10 years of work for those. When I get any free time I feel it would be better spent going through my list of older programs that I can easily cut time from. 

Sorry for the novel. TIA for any help. 

[John_Carpenter]

Hi jwvt88-

 

Lemoines has been doing this type of work for a long time. Years ago when doing some joint projects with high speed milling on Makino machines in the Detroit area I dealt with several Lemoines customers. Like your scheduling guy has said - it is very important to get the data in the header correct. If this means that you need to modify the post processors to get them to post out consistently then I would say yes - make that happen. You are entirely correct when you state that you need to come up with a standard. That will require a group effort and input from all the stakeholders at your company involved. I have witnessed this countless times as we have implemented communication and monitoring systems for clients for nearly 30 years. The data inconsistency is no ones fault directly - just that there was an evolution of platforms (UNIX to DOS to Windows) and Programmers (they sometimes come and go and each have their 'own style'). Sometimes there are multiple programming packages that have played a role as well. The best way (without implementing a vaulting or database driven software) is to get a handle on the situation by first agreeing on how to name the actual G-code file.                    An example would be similiar to what you referenced ( PARTNAME=A2345876-30-A-B-15.NC)   In this example the drawing is A2345876, the operation is 30, the drawing revision is A, the tape revision is B, and it was programmed for machine type 15 (usually when a programmer is making a program he has a particular machine in mind that he wants to cut the part on)  I have seen many variations of the above example thru the years but the key is consistency and communication. After time everyone can identify the tag in the file and understand from original designer to machinist, scheduler, expediter, etc. and if for some reason that file ends up in an email, usb stick, on the desktop, - then someone can say - oh that is an NC file that makes this particular part.

As your shop moves further down the Industry 4.0 road and gets deeper into the Digital Twin and IIOT then the constancy you have in your department will be much appreciated. In addition to the file naming conventions established, i have seen folders setup for specific purposes with each machine Proven, Release, Outbox, Inbox, Archive (Again this is not necessarily with the large shops that are using vaulting database driven systems). They use a constant process where aligning expectations between departments is key. This is a good challenge for you to help solve at the programming level and you certainly will be in a better spot as a department and company once this is working. The scheduler will be happier, the machinist will be happier and out of more order you will directly help the throughput and monitoring situation from a managerial level. If you want to talk about it further feel free to reach out to me or any of the people at our facility and we would be glad to help.

Best Regards,

John Carpenter

www.excellerant-mfg.com