I wanted to know if OptaPlanner has been implemented in any oil and gas planning tools? The main difference I see between the application in Oil and Gas industry and the normal Project Job Scheduling is: in O&G, if your facility doesn't have enough room for inventory, you may choose to shut-in or turn down the production of some existing producing wells and make room in the facility for new wells to be scheduled just like normal project job. I wonder if the additional optimization in determining how much producing wells should be turned down to can be solved in OptaPlanner?
Related
I'm working on assembling a LabVIEW setup that has the ability to measure Pressure, Temperature, RPM, Voltage and Amperage. I believe I have identified the correct modules but am looking for another opinion before giving anyone a lot of money.
Requirements:
Temperature: Able to measure 7 channels of temperatures ranging from
ambient to 300 degrees F.
RPM: Able to measure shaft RPM up to 3600.
Voltage: Able to measure up to 500 Volts, 3 phase AC.
Amperage: Able to measure up to 400 Amps, 3 phase AC.
Pressure: Able to measure 2 channels of various ranges of PSI
(specific transducers to be identified at a later date).
The Gear:
Chassis: cDAQ-9174 with the PS-14.
Temperature: T type thermocouples and NI-9212.
RPM: Monarch Instrument Remote Optical Laser Sensor and NI-9421.
Laser uses 24 volts but returns 19 volts when target is present and 0
volts when the target is not present.
Voltage*: ATO three phase AC voltage sensor ATO-VOS-3AC500 outputting
0-5 volts and either NI-9224 or NI-9252.
Amperage*: 3, Fluke i400 units returning 1mV per Amp and either
NI-9224 or NI-9252.
Pressure: 2, 4-20mA 2 or 3 wire pressure transducers to be identified
at a later date, and either NI-9203 or NI-9253.
*Voltage and amperage will be measured on the same unit
Questions:
RPM: Will the NI-9421 record a pulse of 19 volts?
Voltage and Amperage: What is difference between the NI-9224 and the
NI-9252, which one would work best for my application?
Pressure: What is the difference between the NI-9203 and the NI-9253
other than input resolution and which one would work best for my
application? Resolution is not a priority.
Overall: Anything stand out as a red flag?
I have not tried any of this equipment out myself.
Thanks in advance for your expertise and patience.
First things first, I would encourage you to strike up a conversation with whichever NI distributor is local to you. Checking specifications and compatibility between sensors, modules, chassis, etc. is very much in their wheelhouse, and typically falls in the pre-sales phase of discussion so you shouldn't need to spend money to get their expertise.
(Also, if you're new to LabVIEW and NI: I very much recommend checking out the NI forums in addition to Stack Exchange. Both are generally pretty helpful communities!)
One thing I'm not seeing in the requirements you listed that would be very helpful are timing requirements/sample rates. What frequency do you need to sample each of these inputs, and for how long? How much jitter and skew between samples is acceptable? Building a table of signal characteristics including: original project specification, specification in units of the measurement device, minimum sample rate, analog/digital, and which module the channel is on will make configuring a chassis to meet your needs a lot easier.
For a cDAQ system the sample rates you measure at, and how many different ones you can run at one time, is determined by the chassis rather than the module. (PCI/PXI data acquisition cards have the timing engine on the card.) For the cDAQ-9174 you can run multiple tasks per chassis but only one task per module. You may need to group your inputs onto modules that run at similar rates to fit into the available tasks. I put a link to NI's documentation of the cDAQ timing engine at the bottom.
Now to try to summarize the questions:
Homer512 is correct about voltage, 11V is the ON threshold. However, the NI-9421 can only count pulses up to 10kHZ into the counter. How many pulses are generated per rotation? Napkin math says one pulse per rotation at 3600RPM means you're capturing a 216kHz pulse stream at minimum. (This is why timing is everything. You also probably don't want to transfer every single pulse to calculate the RPM constantly, more likely you need the counter to sum up the pulses as fast as they happen, and at a slower rate you check to see how many counts went by since your last check-in.)
Homer512 is correct again, NI 9252 has additional hardware filtering before the ADCs. This would be for frequency filters on the input source, not usually something you would use if you're just reading a 5V signal from a sensor.
NI 9203 uses a SAR ADC (200kS/s), NI 9253 uses a Delta-Sigma (50kS/s/ch). Long story short: NI 9253 is more accurate but slower. I'd need more information to make a best for application judgement, specifically numerical requirements on resolution and timing.
Red flags: kinda captured it in the other points, but the project requirements have some gaps. I've had " is not a priority" and requirements in a unit other than the measurement device (RPM vs. pulses/s or Hz) bite me enough times that I highly recommend having it written down even if it's blatantly obvious.
Links may move in the future, and the titles are weird, but here are a few relevant NI docs:
"Number of Concurrent Tasks on a CompactDAQ Chassis Gen II" https://www.ni.com/en-us/support/documentation/supplemental/18/number-of-concurrent-tasks-on-a-compactdaq-chassis-gen-ii.html
"cDAQ Module Support for Accessing On-board Counters" https://www.ni.com/en-us/support/documentation/supplemental/18/cdaq-module-support-for-accessing-on-board-counters.html
I am looking for a plc system for our brewery. I would like buy a second hand PLC with the necessary modules. I have seen the AB SLC500 1747-L542 cpu for a good price (120$) with a lot of modules, but I dont know, if it is new enough for a project. (Windows compatibilty, programming environment, etc)
Should I buy it, or it would be a bad decision? If it is not a good decision, what do you suggest for me? I have seen Siemens S7-200, Siemens ET 200 and others too.
Thank you.
If you want to go cheap, use something from automation direct or ez automation. You not only need a CPU, you need I/O cards, rack, power supply, software & HMI. That's going to be a ton of money up front. With the two vendors I mentioned, they bundle most of that for a much lower cost of entry.
Yes this is certainly new enough to use. However, you will need an entire rack. For instance, a ethernet, devicenet, or io cards to connect the processor to your components.
Also as Bill J mentioned, AB may be industry standard in America, but it is expensive. Depending on your brewery's income it my not be smart. Siemens is the same idea.
Quote from AB's website
Our Bulletin 1747 SLC™ 500 control platform is used for a wide variety of applications. Rockwell Automation has announced that some SLC 500 Bulletin numbers are discontinued and no longer available for sale. Customers are encouraged to migrate to our newer CompactLogix™ 5370 or 5380 control platforms.
link to website
So I would say, for a new project, no it's not worth bying in 2017.
Depending on how many points you need to use I would recommend going with the CompactLogix or MicroLogix from AB. The lowest CompactLogix is my favorit for all around tasks, I have standardized the whole plant to use it as the lowest level PLC for the simplest machines. Built in you get Ethernet capability, 16 inputs, and 16 outputs. You can expand the controller via different modules (up to 8 for the lowest PN), that can include additional discrete IO, analog modules etc.
Do not use a SLC as they are obsolete and even though you can get it to work without much trouble this is not a good choice for a new project.
It is hard to say what you need exactly without knowing the specifics of your project so I would recommend using the "integrated automation builder" (a free download from AB) to properly size a controller for your needs.
Are ARM-JTAG-20-10 and J-LINK 9-PIN CORTEX-M ADAPTER pin compatible? Why such a big price difference?
Apart from the price levels and policies of two different manufacturers ("Why is a fiat cheaper than a porsche if both allow you to cruise at the same max speed of your home country?"), the quality of the electronic hardware may differ notably, which can impact the maximum baudrate you can run with a given target PCB.
Furthermore, some JTAG pinout adapters include additional features like galvanic isolation (I haven't checked whether this applies to the Segger piece you mention.).
How should I decide system requirements like:
RAM capacity
FLASH memory capacity
Processor frequency
etc
I am building an application to control NAND FLASH, LCD driver, UART control, keypad control using a 16 bit micro-controller.
This has to be estimated from previous projects with similar functionality. Or even other people's products. But it is best to develop with a larger capacity and decide on final parts when your software nears completion, because its easier to omit components than to try and find room for them later. This kind of design can be an iterative process, start with one estimate and see if a prototype works, don't commit to volumes until you are nearly at the end.
In the case of an LCD based product, you will have two major components using up flash memory, the code and the LCD data (character strings, bitmaps etc). Its certainly easier to estimate the LCD data than the code, which depends on functionality, compiler optimisations etc. If you are bringing in external libraries then at least you already have code for them.
In any case, have an upgrade plan. The worst thing is to run out of capacity at the end of the project and be struggling to optimise the last feature/debug solution in without adding another problem. Make sure you know what the next size up chips are and how you can get them to fit, sometimes a PCB can be designed to take various different chips in the same position. Or have an expandable system, where you can plug things into a memory bus.
How many units will you be making ?
If your volumes are low (<1e3), but per unit profits high and time to market matters, more hardware will get the developers done sooner.
If the volumes are huge (>1e6), profits per unit low, then you penny pinch the hardware, but time to develop will go up. If time to market matters, that's a tradeoff.
Design the board with 2x the capacity (RAM/flash), but don't load the parts, other than to check it works.
Then if you run out of room, there is somewhere to go.
Will customers expect to get firmware updates ? Or is this a drop-ship product with no support ? Supportable is harder, needs more resources.
You'll need to pad resources to have room to expand into if the product needs support for a long time.
For CPU frequency estimates, how much work is required to be done ?
Get an Eval board for a likely MCU and prove out the core function.
Let us say it's a display for a piece of exercise equipment. Can it keep up with the sensors on the device at 2-3x the designed pace ? That's reading the sensors and updating the display. If cost is required to be low, you can then underclock the eval board adn see what trades can be made.
When selling a software package that requires hardware, typically dedicated hardware (could be a VM), the buyer typically has to buy the server it will run on. So the total cost of ownership (focusing on the capital expense) includes the hardware in addition to the software.
For example, a $3000 bug tracking package might need a $1500 server to run on, total cost is $4500. The hardware is 50% of the software cost, or 1/3 of the total cost.
Of course, with open source packages, the ratio is inverted.
So the question is: does it matter? At what point does hardware expense affect the sale of the software?
Why require hardware at all?
If hardware prices are a big breaking point in your sale, perhaps offer a hosted solution and factor the price into this service.
"Software As Service" might really help you makes some sales for customers with limited infrastructure.
The ratio depends on which part of the equation is the commodity part.
If you are selling a software targeting solving complex problems like air traffic control that can run on any servers, you might want to sell it packaged with the hardware for a bit more, but since the hardware is the commodity and can be obtained from other vendors, the price ratio will be heavily skewed towards the software.
If on the other hand you are OEM and your goal is to sell your hardware, you can use the software as the commodity to bring more value to your offering. For example, you can sell high-endserver machines and add a preconfigured LAMP stack to make your offering better. In this case, the price is heavily skewed towards the hardware.
"typically" - that's an assumption.
And the cost can be more than just hardware and software if there are service or renewal fees involved. This can be true of open source as well, because a lot of companies like to pay for indemnification and services.
If you buy hardware plus operating system, the decision to go with Windows or Linux comes into play.
I doubt very much that there's a meaningful, fixed ratio. It's an interesting question, though. You'd need a LOT of data, and I don't see that it's been gathered into one place.
I had another thought in a comment below that's worth surfacing. There's another consideration that's becoming more important all the time: power consumption. Some corporate data centers can't add a new server without retiring an old one or by reducing power consumption some other way. Being able to deploy a new software purchase on an existing server is big plus. If it can be virtualized, even better.
So it's not always hardware and software. Other economic considerations, like power cost, have to figure in.
I have found that hardware costs rarely affect the decision.
Small companies can get away with reusing servers.
Large companies already support clusters of servers, increasingly with VM capability so it's easy for them to deploy/redeploy software to as much hardware as necessary.